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Preface 

Welcome to IWQOS’97 in New York City! 

Over the past several years, there has been a considerable amount of research within 
the field of Quality of Service (QOS). Much of that work has taken place within the 
context of QOS support for distributed multimedia systems, operating systems, 
transport subsystems, networks, devices and formal languages. 

The objective of the Fifth International Workshop on Quality of Service (IWQOS) is 
to bring together researchers, developers and practitioners working in all facets of 
QOS research. While many workshops and conferences offer technical sessions on the 
topic QOS, none other than IWQOS, provide a single-track workshop dedicated to 
QOS research. 

The theme of IWQOS’97 is building QOS into distributed systems. Implicit in that 
theme is the notion that the QOS community should now focus on discussing results 
from actual implementations of their work. As QOS research moves from theory to 
practice, we are interested in gauging the impact of ideas discussed at previous 
workshops on development of actual systems. While we are interested in experimental 
results, IWQOS remains a forum for fresh and innovative ideas emerging in the field. 
As a result of this, authors were solicited to provide experimental research (long) 
papers and more speculative position (short) statements for consideration. 

We think we have a great invited and technical program lined up for you this year. The 
program reflects the Program Committees desire to hear about experiment results, 
controversial QOS subjects and retrospectives on where we are and where we are 
going. 

The IWQOS invited program is made up of a keynote address, panels and a workshop 
paper. The keynote address is by Aurel A. Lazar (Columbia University) on realizing a 
foundation for programmability in telecommunications networks entitled 
"'Programming Telecommunications Networks'". The invited panels address two 
aspects of delivering QOS in distributed computing environments and the Internet. The 
first panel, chair by Douglas Schmidt (Washington University), addresses the question: 
"QoS for Distributed Object Computing Middleware - Fact or Fiction?"". Next, 
Henning Schulzrinne (Columbia University) chairs a panel on the provision of QOS in 
the Internet: "Reservations about Reservations"". To complete our hot invited program, 
we have a reality check in the form of the workshop invited paper by Ralf Steinmetz 
and Lars Wolf on "Quality of Service - Where are we ?"". 

The IWQOS invited program is complemented by a strong technical program that 
includes twenty long papers and twenty short papers. More than seventy papers from 
nine countries (including America, Europe, Australia and Asia) were submitted for 
consideration. The quality of this year’s papers is excellent. This leads to a very strong 
technical program that neatly falls into ten sessions: mobile communication, QOS 
routing, advanced reservation, traffic management, QOS and video systems, 
distributed object computing, QOS management, QOS-based transport protocols, QOS 
mapping and QOS adaptation. 
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The Program Committee would like IWQOS’97 to be an interactive workshop and not 
a sit and listen conference. To reflect that goal, we have a general session format of 
two long and two short papers followed by a thirty minutes panel session on topics 
raised during the session. 

Finally, we would like to thank the Program Committee for all their efforts in making 
this a successful workshop, the Center for Telecommunications Research at Columbia 
University for hosting this year’s workshop and to the local Organization Committee 
(particularly, Koon-Seng Lim and Oguz Angin) for all their hard work. 



Enjoy! 

Andrew T. Campbell and Klara Nahrstedt 
May 1997 
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Abstract 

This paper presents a summary of the fifth International Workshop on Quality of Service 
(IWQOS). The goal of this three-day meeting was to foster interaction between researchers 
active in the area of Quality of Service (QOS) research, to reflect on past experiences and 
lessons learnt, and to discuss future QOS challenges. To reflect this goal, this year’s workshop 
included a hot program made up of (i) a keynote address on “Programming 
Telecommunications Networks”; (ii) panels addressing “QOS for Distributed Object 
Computing Middleware - Fact or Fiction?” and “Reservations about Reservations”; (iii) a 
workshop invited paper entitled, “Quality of Service - Where are we?” and (iv) ten technical 
sessions that included new topics for IWQOS such as mobile communications, QOS routing 
and QOS-based transport systems. This report summarizes the technical program and captures 
the main themes and major areas of discussion that emerged during IWQOS ’97. 

1. Introduction 

Over the past several years, there has been a considerable amount of research within 
the field of Quality of Service (QOS), Much of the work has taken place within the 
context of QOS support for distributed multimedia systems, operating systems, 
transport subsystems, networks, devices and formal languages. The objective of the 
International Workshop on Quality of Service (IWQOS) is to bring together 
researchers, developers and practitioners working in all these facets of QOS research. 
While many conferences and workshops offer technical sessions on the topic QOS, 
none other than IWQOS, provides a single-track workshop dedicated to the broad 
subject of QOS research. 

The 5*** IFIP International Workshop on Quality of Service was held at the Center for 
Teleconununications Research, Columbia University, and is the latest in a series of 
continuing workshops. The first workshop, held in May 1993 in Montreal, Canada, 
was supported by the European RACE project QOS TOPIC and the Canadian CITR 
project Broadband Services. The second workshop, organized within the European 
RACE Conference on Integrated Services and Networks (IS&N), took place in 
September 1994 in Aachen, Germany. The third workshop was held in February 1995 
in Brisbane, Australia, in conjunction with the International IFIP Conference on Open 
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Distributed Processing. In March 1996, the workshop was held in Paris in conjunction 
with the IFIP/IEEE International Conference on Distributed Platforms. 

The theme for IWQOS’97 was “Building QOS into Distributed Systems”. Implicit in 
the theme is the notion that the QOS community should focus on discussing results 
from prototype implementations of their ideas. We were naturally interested in 
assessing the impact of ideas discussed at previous meetings on future products as 
QOS ideas move from research to development. While IWQOS is interested in 
experimental results, it remains a forum for the discussion of fresh and innovative 
ideas. As a result of this, authors were solicited to provide experimental research 
(long) papers and more speculative position (short) statements. The technical program 
successfully reflected the organizers desire to hear about experimental results, 
controversial ideas, retrospectives and future directions. 

2. IWQOS’97 Program Outline 

This year’s workshop included an invited program, which comprised a keynote 
address, panels and a workshop invited paper. The keynote address given by Aurel A. 
Lazar (Columbia University) was entitled “Progranuning Telecommunications 
Networks”. The invited panels addressed two aspects of delivering QOS in distributed 
computing environments and the Internet. The first panel, chaired by Douglas 
Schmidt (Washington University), addressed the question: “QOS for Distributed 
Object Computing Middleware - Fact or Fiction?”. The second workshop panel 
entitled “Reservations about Reservations” and chaired by Henning Schulzrinne 
(Columbia University), discussed the topic of QOS provision in the next generation 
Internet. To complete the IWQOS’97 invited program, we had a reality check in the 
form of the workshop invited paper by Ralf Steinmetz and Lars Wolf (Darmstadt 
University) on “Quality of Service - Where are we?”. 

A strong technical program that included twenty long papers and twenty short papers 
complemented the IWQOS invited program, which were chosen from more than 
seventy papers from nine countries. 

3. Programming Telecommunications Networks 

Keynote Speaker: Aurel A. Lazar, Columbia University 

Recent moves toward market deregulation and open competition have sparked a wave 
of serious introspection in the telecommunications service industry. Telecom 
providers and operators are now required to open up their primary revenue channels 
to competing industries. In the keynote address, Aurel Lazar [Lazar,97] focussed on 
the problem of progranunability of telecommunications networks for new services. 
The speaker outlined an agenda for realizing an open programmable networking 
environment based on the concept of a broadband kernel that better reflects the 
service creation and deployment environment and economic concerns of future 
telecommunications systems. 
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The address began with an examination of the service structure of two major global 
conununication networks (i.e., the Telephone Network and the Internet) exploring 
their relative strengths and weaknesses. Lazar proposed a three-tiered open service 
model that reflects the economic market structure of the future telecommunications 
service industry. He considered that the lowest layer of the model reflected a 
hardware market where numerous equipment manufacturers and vendors offer 
hardware and firmware solutions for building the basic communication infrastructure. 
The customers of this market are typically network carriers, third party software 
developers who specialize in developing software for service providers and a handful 
of service providers themselves. The Application Programmer Interfaces (APIs) 
provided by vendors in this market would allow users to write basic communication 
services and middleware components. He considered that the second layer of the 
model reflects a middleware service market where carriers, software developers and 
middleware service providers offer middleware service products to customers who are 
in the user service provisioning business. The APIs provided in the middleware 
service market are suitable for development of consumer level services. Finally, at the 
highest layer he considered that the model reflects a consumer services market where 
consumer service providers compete to bundle, integrate and customize their wares in 
the most appealing form for mass market consumption. Within each market there may 
exist brokers whose role is to mediate the interaction and dealings between buyers 
and sellers who, because of regulatory and business policies, cannot transact directly. 

The keynote speaker commented that this service model falls somewhere between the 
Internet’s peer-to-peer model and the Telephone Network’s strict provider-customer 
model. In essence, it allows for cooperation between any number of entities in the 
network for realizing a common service as well as the competition among services for 
network resources. The corresponding engineering model can be parameterized in 
such a way that the basic characteristics of the peer-to-peer model as well as the 
characteristics of the provider and consumer model can be accommodated. Within 
each layer (which models a particular market), players are free to enter and buy, sell 
or re-bundle each other’s services. Across layers, the relationship reflects the 
traditional provider-customer model. 

Lazar argued that investigating such a model would help clarify some important 
issues facing the teleconununications service industry as it deals with changes in 
service needs. An engineering model for realizing the open service market model was 
then presented as a vehicle for creating multimedia services on broadband networks. 
An example of engineering some of the components of the open service model was 
then presented from an implementation viewpoint. 

In an insightful presentation the speaker connected abstractions with real-life 
implementation reinforcing major themes of the keynote. At one point, Lazar 
presented a model of a schedulable region (which represents the resource capacity of 
a switch multiplexer) as a live feed from one of the ATM switches in Columbia’s 
broadband network. The schedulable region was configured and managed using a 
QOS extended version of Ipislon’s General Switch Management Protocol (GSMP) 
called qGSMP developed by the COMET Group at Columbia. To bring the audience 
closer to the problem of engineering a solution, the speaker incorporated Java applets 
to illustrate live feeds from switches in the COMET laboratory. The audience clearly 
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saw a representation of a schedulable region and its operational points changing 
dynamically as the traffic through the switches in the testbed varied over time. Such 
illustrations helped to showcase several important points of this spirited and 
informative keynote address. 

4. Technical Sessions 

IWQOS’97 was a truly interactive event. The general format of each of the ten 
technical sessions included long and short papers followed by a thirty minute panel 
discussion on topics raised during the session and in response to questions from 
audience. 

The ten technical sessions comprised: mobile communications, QOS routing, 
advanced reservation, traffic management, QOS and video systems, distributed object 
computing, QOS management, QOS-based transport protocols, QOS mapping and 
QOS adaptation. 



4.1 Mobile Communications 

Chair: Mahmoud Naghshineh, IBM 

The opening session of the workshop investigated the feasibility of delivering 
continuous media with QOS guarantees in mobile networks. A key observation of the 
session was that providing QOS support in a wireless and mobile environment 
requires a fundamentally different approach from that found in wireline networks. 
The session included two long and four short papers. 

Presentations 

The first talk was given by Bharghavan [Lu,97], University of Illinois at Urbana- 
Champaign. Bharghavan proposed a number of solutions to the problem of providing 
sustained QOS to mobile applications. Limited and varying resources availability, 
stringent application requirements and user mobility make providing QOS guarantees 
in mobile and wireless environments challenging. He introduced an adaptive service 
model that enables the network and mobile applications to renegotiate QOS 
depending on dynamic network conditions. Following this he described an 
algorithmic framework that provides cost-effective resource adaptation in the 
presence of resource dynamics. Bharghavan concluded by arguing for a unified 
architecture for QOS adaptation. 

The next presentation, by Stephen Wade [Blair,97], Lancaster University, addressed 
the design of a distributed systems platform and algorithms for mobile computing 
environments. The platform, called Limbo, aims to support the development of 
demanding mobile-aware distributed applications in a heterogeneous networking 
environment. Limbo is based on the concept of tuple spaces, which has been extended 
for the mobile computing environment to support QOS management. Limbo places 
emphasis on QOS monitoring and adaptation. The speaker argued that the tuple space 




Workshop Summary 



xvii 



paradigm was particularly useful in modeling adaptation to changes in network 
connectivity in mobile networking environments. 

The third talk of the session, by Badrinath [Badrinath,97], Rutgers University, 
focused on architectural support for Internet cellular telephony. It was evident to 
Badrinath that those who designed RSVP and the integrated service architecture had 
not looked at mobility issues. In contrast, those that developed mobile-IP had not 
addressed QOS issues. The speaker made an argument to unify some of these 
disparate pieces in support of cellular phone services. The proposed service was based 
on an IP network capable of delivering packetized voice to moving users. Badrinath 
calls the solution “RSVP+mobilelP+QOS”. 

Next, Andrew Campbell [Campbell,97], Columbia University, discussed a number of 
QOS challenges for next generation mobile middleware. The speaker reflected that 
the area of QOS and mobility was in its infancy. The wireless media systems project 
at Columbia was attempting to shine some light on the subject by building a prototype 
QOS-aware middleware platform for mobile multimedia networking called 
mobiware. The platform is programmable and runs on mobile devices, base stations 
and mobile-capable switches. Mobiware includes a new active and adaptive 
transport, QOS controlled handoff algorithms and an adaptive network QOS model. 

The next speaker, Javier Gomez-Castellanos [Gomez,97], Columbia University, 
presented results showing the effect of transmission errors on MPEG streams over 
wireless links. The speaker proposed several algorithms that improve the perceptible 
quality of MPEG streams during periods of fast and slow fading. Gomez-Castellanos 
suggested an algorithm based on a combination of Forward Error Correction (FEC) 
and Automatic Repeat Request (ARQ) as a way to minimize the impact of error 
characteristics on video in this instance. He introduced a packet tagging technique 
that takes into account the particular semantics of MPEG flows and the relative 
importance of different packets (e.g., GOP, headers, IPB, scalable profiles) as they 
traverse a mobile network. 

In the final presentation of the session, Steven Pope [Pope,97], Olivetti and Oracle 
Research Laboratory, discussed QOS support for mobile computing environments. 
There is a demand for completely portable computers (which Pope called 
walkstations) to access the network while traversing both indoor wireless LAN 
networks and the outdoor mobile radio network infrastructure. The speaker 
introduced a traded handoff where connections are rebuilt during a handoff to the 
most appropriate service, taking into account the properties required by the 
application and locally available, replicated or compatible services. 

Panel Discussion 

At the end of this session, the question of how to provide QOS in wireless and mobile 
environments was raised. The session chair presented two opposing views for 
consideration by the panel where the mobile network provided: 

• hard guarantees, in which case there was no need for adaptation mechanisms in 
applications - as in the case of future wireless ATM networks; and 
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• no guarantees, in which case there was a strong need for highly adaptive 
mechanisms in the applications - as in the case of today’s best effort mobile IP 
network. 

Many of the panelists thought that QOS offered by future mobile multimedia 
networks would operate somewhere between the two extremes. The panel considered 
supporting hard guarantees for a wide range of multimedia traffic unrealistic given the 
nature of the wireless medium and mobility requirements. Bharghavan stated that 
there seems to be universal acceptance that an intermediate service be based around 
an adaptive resource management model. This approach benefits by reducing handoff 
dropping probability and increasing the utilization of the network. 

Mahmoud Nagshineh followed up with another question to the panel: if there was 
agreement on an adaptive resource management then where should the adaptive 
algorithms reside: at the physical, MAC, network, transport or application layers? If 
applied solely to application layer, this would result in low cost and minimal 
complexity in the network. On the other hand, if the network explicitly supports 
adaptation then this would result in high cost and increased network complexity. 
Weighing these arguments the panel agreed that there was need for research into 
adaptation support in the network and the end-system. 

Toward the end of this lively discussion, there was a question from the audience 
concerning the relationship between pricing models and adaptive mobile multimedia 
environments. Badrinath explained Uiat clearly there would be a premium cost for 
mobile over mobile incapable users - as exists today in cellular telephony systems. 
The issue is what would the policy be when a user service is forced to degrade to a 
lower quality; how do we cost that likelihood? Badrinath speculated that while users 
currently pay a premium for mobility they would naturally expect a discount from the 
provider as a consequence of network initiated QOS degradation. 

4.2 Traffic Management 

Chair: Ed Knightly, Rice University 

The four long papers presented in the traffic management session approached the 
QOS traffic management problem from various angles and proposed widely differing 
solutions. The first paper considered the worst case traffic pattern for source policing 
as an integral part of the traffic model. The second and third papers focused on 
Markovian modeling techniques, while the fourth advocated a measurement-based 
approach. 

Presentations 

Philippe Oechslin [Oechslin,97], University College London, presented the first talk 
of the traffic management session on the topic of myths of on-off sources. This was in 
relation to the worst case arrivals of leaky bucket constrained sources. Simulation 
results from a set of independent connections limited by leaky bucket shapers and fed 
into a buffered multiplexer were presented. Oechslin indicated that this scenario was 
typical of an ATM switch or in a looser sense typical of an RSVP capable router. 
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Results from the analysis found periodic traffic patterns resulted in poorer loss rates 
over the on-off or tri-state patterns models. The results invalidate the widespread 
belief that on-off patterns are the worst case traffic of independent leaky bucket 
constrained sources. 

The second paper, given by Hoon Lee [Lee, 97], Korea Telecom, presented a cell 
access control scheme for guaranteeing multiple classes of cell loss QOS 
requirements in an output buffer of an ATM switch. Lee proposed a class acceptance 
controller, which regulates the acceptance of the cells of QOS classes, based on the 
dynamic state of the queues. He considered decision functions for the class 
acceptance controller with a view to comparing their effects to the QOS performance. 
Queueing analysis of the scheme derived a number of performance measures. The 
implications of the work were further illustrated using a number of numerical 
experiments. 

The third paper, by Dietmar Becker [Becker,97], Aachen University of Technology, 
reported on queueing analysis for a partial buffer system with discrete Markovian 
arrival processes. An evaluation of the performance of the partial buffer system with 
finite capacity, deterministic service time and multiple sources was presented. A 
discrete Markovian arrival process modeled each source. The queueing system was 
evaluated for several traffic compositions and different sizes of the shared buffer area. 
Becker considered a number of traffic compositions including VBR sources with 
periodical or negative exponential correlation functions and CBR traffic with fixed 
interarrival cell emission. The probability distribution of the cell loss of each source 
was presented. 

The final talk of the session, on real-time estimation of the link capacity in 
multimedia networks, was presented by Piergiulio Maryni [Maryni,97], DIST- 
University of Genoa Maryni suggested that simple but powerful abstractions that 
represented the capacity of multimedia networks are needed. In order to guarantee 
QOS, the link capacity must first be calculated, i.e. the total number of calls of 
different types that can be admitted on a single link at a given time. The speaker used 
the notion of a schedulable region to represent the link capacity for an ATM 
multiplexer. Maryni presented a new approach for computing the schedulable region 
in real-time which could be used as input to admission controllers. The methodology 
relies on real-time QOS measurements to dynamically compute the size and the shape 
of the region. No assumptions about traffic resource models or scheduler operations 
were needed for its construction. 

Panel Discussion 

The panel discussion began by addressing the role of traffic models in delivering 
QOS guarantees. The panel recognized the difficulty in traffic modeling and the 
complexity of meeting traffic characteristics and adapting to a wide variety of user 
applications needs. Most of them agreed that the measurement-based approach could 
significantly relieve some of the difficulty inherent in many traffic models proposed 
in the literature. 
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Ed Knightiy commented on the weakness of measurement-based resource allocation, 
whose inaccuracy lies in the measurement procedure that averages out the 
heterogeneous behavior of traffic flows. The panelists believed that Markovian 
modeling and worst-case analysis can still play roles that complement measurement- 
based approaches; that is, in supporting new types of traffic where measurement data 
is not available, or in planning backbone networks where the requirement on the 
modeling accuracy is relaxed due to the multiplexing of a large number of flows. 

Lee indicated that in the backbone networks, resources are conservatively 
dimensioned so that the control algorithms are not sensitive to the inaccuracy caused 
by measurement algorithms. This led to a debate initiated by Maryni on whether 
traffic modeling is needed at all. In future, he rhetorically argued, why use traffic 
modeling techniques when network capacity may be infinite? Since traffic modeling 
aims at increasing bandwidth utilization, with the abundance of bandwidth this may 
disappear like the technique for reducing the number of transistors in circuit design. 
Oechslin added that abundant bandwidth availability would be a reality now if the 
right pricing model were in place to generate enough revenue to turn on more 
bandwidth. 

4.3 QOS Routing 

Chair: Mischa Schwartz, Columbia University 

The basic goal of QOS routing is to select a path through the network that satisfies a 
set of QOS constraints while achieving some level of network resource utilization. 
The first two long papers in this session presented differing approaches to achieving 
this goal. Following this, Scott Corson, Maryland University, joined the panel 
discussion and raised a number of open issues in providing QOS support when 
routing flows through mobile ad-hoc networks. 

Presentations 

The first talk given by Qingming Ma [Ma,97], Carnegie Mellon University, 
addressed the issue of QOS routing for traffic with performance guarantees. The 
speaker presented some initial results on QOS path selection for traffic flows 
requiring bandwidth, delay and jitter guarantees. For traffic that required bandwidth 
guarantees, it was found that several routing algorithms that favored paths with fewer 
hops perform well. Ma argued that a modified version of the Bellman-Ford shortest- 
path algorithm in polynomial time was sufficient for traffic with delay guarantees. He 
showed that the problem of finding a path that can satisfy bandwidth, delay, jitter, 
and/or buffer could be solved while at the same time deriving the bandwidth that has 
to be reserved to meet these constraints. 

S. Verma [Verma,97], University of Toronto, reported on QOS based routing in 
support of emerging multicast multimedia communications. Verma proposed a 
routing metric that could be used in combination with heuristic algorithms to find the 
multicast tree for guaranteed QOS services. The optimum tree used in the formulation 
was a delay-bounded minimum Steiner tree. Simulation results showed a marked 
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improvement in network utilization expressed in terms of cost over other proposed 
schemes such as QOS path first routing. 

Panel Discussion 

The panelists were asked by the audience to clarify the relationship between routing 
and resource reservation for end-to-end QOS guarantees. Ma stated that the first goal 
is to discover a path and then reserve the resources along the path or reject the 
flow/call if resources are not available. Other approaches handle routing and resource 
reservation at the same time - connection oriented systems couple routing and 
resource reservation. 

The issue of state management was debated. An objective of QOS routing is to 
distribute state information that accurately reflects available resources on a particular 
path. Probabilistically resources may not be available at a certain switch/router if the 
state is old. The panel discussed the implication of QOS state management and 
concluded that it needs to realistically represent available resources. In the past, call 
setup used crank-back techniques to resolve inconsistencies in the QOS routing state 
representation. 

Scott Corson [Corson, 97] described the generic character of routing in mobile ad-hoc 
networks. He highlighted some of the differences between ad-hoc and wireline 
multihop networks and the impact these differences had on QOS-based delivery 
systems. Corson suggested that supporting QOS in ad-hoc networks was an extreme 
challenge. Wireless QOS architectures must provide a balance between network and 
application-level QOS adaptation. This, he argued, would help minimize QOS-related 
signaling which has traditionally been integrated with routing state to support a given 
QOS. Corson concluded by saying that two approaches seemed to warrant further 
investigation for ad-hoc services; namely, minimal guaranteed QOS and probabilistic 
QOS. 



4.4 QOS and Video Systems 

Chair: Alexandras Eleftheriadis, Columbia University 

There are two schools of thought related to QOS and video systems. One school 
argues that resource reservation is essential for video services. The other argues that 
the network need only be engineered to support best effort services. In this case 
networked video systems need only estimate resource availability and intelligently 
adapt to the observed state. This session included two long and two short papers that 
reported on adaptive QOS driven video systems. 

Presentations 

Sanjay Jha [Jha,97], University of Technology, Sydney, proposed a set of playout 
management algorithms for interactive video. The work examined problems 
associated with display of live continuous media. Under the assumption that the 
network cannot guarantee the required bounds on delay and jitter and the operating 
system scheduling is non-real time, there is a need to acconunodate the delay and 
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jitter in the end systems in order to maintain a desirable QOS. Jha proposed a method 
of video playback that requires accurate estimation of display cycle time of video 
frames and the delay suffered by frames in packet networks. Deterministic forecasting 
methods used in time series analysis were applied to experimental data collected from 
video transmission. 

The second paper by Rajeev Koodli [Koodli,97] proposed the notion of noticeable 
loss, which directly relates loss pattern to the perceived QOS for an application. 
Noticeable loss was used to evaluate resource management algorithms that provided 
QOS to individual adaptive applications. Simulation results illustrated the 
performance of the algorithm. 

D. Bourges Waldegg [Waldegg,97], ENST, presented a temporal QOS based CPU 
scheduling model for multimedia. The model is based on a playout specification and a 
runtime application structure that allows workahead processing and quality 
degradation for delay during overload conditions. Policy is used by a scheduler to 
degrade the service in a meaningful way with the goal of supporting better resource 
utilization. Waldegg added that the run time structure supported workahead 
processing which had shown benefit particularly in the case of overload. 

The last talk by Steven Jacobs [Jacobs, 97], Columbia University, proposed that 
networked video systems could operate sufficiently well over best effort networks. 
Architecting support for video service in packet networks required the addition of a 
number of valued added algorithms. Jacobs stated that there was great demand for 
such services today. Furthermore, he speculated that the demand would persist in the 
future even when many networks supported multi-level QOS assurances. An Internet- 
based video delivery system was presented which combines both image processing 
and networking techniques. Jacobs presented the results from several experiments that 
utilize a combination of bandwidth estimation and dynamic rate shaping of video 
sources. 

Panel Discussion 

Alexandros Eleftheriadis led a lively discussion that addressed a number of issues 
raised in the session and then opened the floor for questions. The first question 
concerned media scaling techniques. Eleftheriadis commented that the choice of 
either frame dropping or quality reduction within a frame (i.e. dropping transform 
domain coefficients) is strongly content dependent, which can vary along the wide 
spectrum of applications. Some applications, such as movies, have scenes that tolerate 
little content loss and require real-time delivery, thus they would have difficulty with 
best-effort delivery. 

The panelists discussed whether hardware solutions for video can alleviate many of 
the problems experienced using software implementations. Jacobs argued that 
hardware support for video is improving and one should address other problems 
instead of duplicating hardware solutions in software. Eleftheriadis pointed out that 
the types of hardware assists are converging as content providers only use limited set 
of encoding standards. However, Jha argued that even for the audio codec, many 
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interoperability problems remain. In today’s Internet, lack of QOS support means that 
researchers have little choice but to use flexible software solutions. 

The last question from the audience addressed the pros and cons of dynamic rate 
shaping and quantization. Jacobs pointed out that dynamic rate shaping is better than 
the quantization technique when the required rate reduction is small. Dynamic rate 
shaping simply drops some coefficients, requires less state information to be 
propagated, and offers better quality under this scenario. In other words, quantization 
pays the penalty for SNR and speed as long as the required reduction ratio is not too 
large. When a large reduction is needed, however, quantization techniques are 
superior. 

4.5 QOS Management 

Chair: Andreas Vogel, Visigenic Corp, 

The next session, chaired by Andreas Vogel from Visigenic, included two long and 
three short papers. Each of these papers focussed on the issue of QOS management 
techniques. The presentations covered both architecture and implementation research, 
with topics ranging from QOS support in operating systems and file systems, end-to- 
end specification, adaptive QOS architecture and QOS management agents. 

Presentations 

The first paper, presented by Lakshman [Lakshman,97], Intel, reported on an 
integrated approach to CPU and network 10 QOS management. Lakshman illustrated 
the challenge of proving predictable QOS for multimedia applications. In such an 
environment applications may not know their exact resource requirements in advance 
and resource requirements and resource availability may be time-varying. To address 
these challenges, Lakshman proposed a resource management architecture in which 
applications and the operating system cooperate to dynamically adapt to variations in 
the resource requirements and availability. 

The topic of QOS management of integrated services communication systems was 
addressed next by Roland Bless [Bless, 97], University of Karlsruhe. It is likely that 
such networks will support a wide variety of applications that will be multiplexed into 
different service classes. Bless reported on a flexible QOS management scheme for 
such conmiunications environment. The approach provided flexibility in tailoring the 
QOS management to suit specific service profiles. Bless outlined the implementation 
of the QOS management system and presented performance measurements to 
illustrate the approach taken. 

Next, Stefan Fischer [Fisher,97], University of Montreal, presented a decentralized 
scheme for cooperative QOS management. The system supports QOS management 
functions such as QOS negotiation and adaptation over the network. The speaker 
suggested that the work was especially suitable for multicast multimedia 
communications. Fisher introduced the notion of QOS agents, installed throughout the 
system where QOS negotiations occurred. QOS agents communicate with their 
neighboring agents. This communication is application oriented, i.e. the agents know 
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about QOS requirements and negotiated values on behalf of the users. Fischer 
concluded by discussing the construction of applications based on the notion of 
cooperative QOS management. 

Jan de Meer [de Meer,97], GMD Fokus, reported on the specification of end-to-end 
QOS control. The speaker distinguished between the QOS control demands for 
continuous and discrete media. Classic control theory seemed an appropriate vehicle 
to monitor and respond to time varying quality as flows progress through the 
communications system. De Meer introduced a “water-level monitoring” paradigm 
which consists of four components, namely, a source, container, monitor and sink, to 
assist in the QOS management process. 

The final talk of the session, presented by M. Spasojevic [Borowsky,97], HP Labs, on 
using attribute-managed storage to achieve QOS. The speaker argued that 
specification of storage systems by means of user-oriented QOS attributes is the key 
to ease of use and efficient resource utilization. Currently, most existing storage 
management is too low level requiring the user to allocate and configure arrays of 
disks. However, little help is provided in helping the user do this. Attribute-managed 
storage systems hide details of the underlying storage systems through virtual storage 
abstractions, units of storage with QOS guarantees. The speaker described a prototype 
matching engine called Forum currently under development. 

Panel Discussion 

The first question from the audience addressed existing operating systems: are they 
sufficient to support integrated QOS? Many panelists thought that work needs to be 
done before a QOS-driven operating system would be available on the market. 
Lakshman, from his experience with using Solaris, conunented that the hardware 
already has a high-resolution clock, whereas he considered his enhancements to the 
operating system targeted faster preemption and better estimation of computing time 
operations. 

A member of the audience asked whether the whole area of QOS management 
research is well understood. The panel observed that there is still a lack of experience 
with QOS management systems, with QOS mapping across layers, and with QOS 
specifications. They believed that the research would shift to toward building large- 
scale prototypes. This would depend on the availability of a large-scale network 
testbed. 

Finally, Fisher commented that the IP networking view of QOS management 
architecture is that it was far too complex. It may be best to revisit fundamental 
control theory, focus on different time-scales and develop simple solutions. 



4.6 Distributed Object Computing 

Chair: Douglas Schmidt, Washington University at St. Louis 

Distributed object computing technology has been widely applied to resolve problems 
stenuning from the complexities of developing large heterogeneous software systems. 
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This session focuses on some of the QOS issues that surround the use of distributed 
object-computing technologies. Issues addressed ranged from QOS parameterized 
trading services to QOS meta-data management for middleware. This session 
included two long and three short papers. 

Presentations 

The first presentation of the session, by Claudia Linnhoff-Popien [Linnhoff- 
Popien,97], Aachen University of Technology, addressed the integration of QOS 
constraints into the service selection process. The major challenges addressed by the 
work were the formulation and evaluation of customized CORBA traders. A service 
distance is computed between the client and the service offers taking into account 
QOS properties. The modified trader selects the service with the minimal distance to 
the service request. The Orbix trader was used to evaluate this QOS metric. Claudia 
Linnhoff-Popien concluded her talk by describing some implementation results in 
comparison to an unmodified Orbix trader. 

The next paper, presented by W. Almesberger [Almesberger,97], EPFL, surveyed 
QOS in communication APIs. The speaker first contrasted the RSVP and ATM UNI 
APIs and distinguished how QOS was exposed to the applications using WinSock 2, 
X/Open and Arequpa. A natural consideration is the mapping of these APIs to local 
operating system and network resources. Almesberger went on to summarize how 
these APIs enable applications to control QOS for their connections/flows. Each API 
has its own idiosyncrasies (e.g., native ATM APIs deal in cells and RSVP APIs in 
bytes) and supports a different set of QOS parameters and traffic characterizations. 
The speaker proposed the unification of QOS description using better abstractions to 
resolve idiosyncrasies found in existing APIs. 

In the third talk, John Zinky [Zinky,97], BBN, reported on managing systemic meta- 
data for creating QOS-adaptive CORBA applications. Zinky made the point that 
distributed applications must be able to adapt to quite diverse operating conditions. 
The speaker introduced the notion of systematic meta-data^ which captures how 
applications utilize distributed systems technology such as CORBA, adapt their QOS 
requirements, use of resources, and allocation policies. In this position statement, 
Zinky discussed some possible solutions. Meta-data required support from the 
network, distributed system and applications. The network needs to support explicit 
mechanisms for moving and storing meta-data. Application programmers need APIs 
for QOS at the client/object boundary rather than at the socket level. 

The fourth paper in this session was presented by D. Reed [Reed,97], Stirling 
University, on supporting QOS components in distributed environments. A key 
component required in such an environment is QOS monitoring services. In his talk 
Reed proposed a generic distributed monitoring service which adapts to suit particular 
applications as a means of overcoming the complexity of specialized monitoring 
solutions. A number of examples highlighted the flexibility of the monitoring service. 

In the final talk of the session, Andrew Grace [Smith,97], British Telecom, reported 
on a QOS configuration tool for distributed applications. The range of distributed 
applications has increased dramatically over the past several years fuelled by the 
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growth of the Internet. Many applications tend to require user level knowledge of 
low-level technical parameters requiring an appreciation of system heterogeneity 
issues rather than simply stating what service they require. In this presentation Grace 
described a working system for QOS configuring for Mbone conferencing 
applications. QOS profiles were adopted as a means of specifying resources and 
requirements in the end-system and networks. 

4.7 Advanced Reservation 

Chair: Hideyuki Tokuda, Keio University 

Is there a need to make reservations in advance? In this session, a number of speakers 
argued that there are sets of applications that require a high degree of resources 
availability in advance. The first paper took an empirical look at advance reservation 
from the network viewpoint. The second and final paper in this session reported on 
scalable video-on-demand systems that utilizes advanced reservation techniques. 

Presentations 

Olov Schelen [Schelen,97], Lulea University, began this session with a presentation 
on sharing resources through advanced reservation agents. The speaker proposed an 
architecture where clients make advance reservations through agents responsible for 
advance admission control. The agents allocate resources in the routers just before 
they are needed for packet forwarding. Schelen illustrated that network resources can 
be shared between immediate and advance reservations applications without pre- 
partitioning. Admission control decisions for immediate reservations use information 
about resources to be allocated for advance reservations in the near future. The 
speaker introduced a new parameter in the admission control algorithm for the 
lookahead. 

Next, Abdelhakim Hafid [Hafid,97], Computer Research Institute of Montreal, 
proposed a scalable video-on-demand system that uses advanced reservation 
techniques to support services. Typically, video-on-demand systems check whether 
there are enough available resources to deliver the requested movie to the user’s host. 
Given sufficient resources, the movie presentation will commence, otherwise, a 
rejection is sent back to the user. Hafid described an advanced reservation signaling 
system called NAFUR. If a QOS request for a video stream cannot be inunediately 
supported at the desired rate NAFUR determines at which point in advance of the 
current request time the video can playout at the desired rate. If the user wishes to 
only accept the desired rate, the system makes use of advanced reservation to book 
resources ahead of time for the duration of the video-on-demand. 

Panel Discussion 

Steve Pink and Lars Wolf joined the presenters and Hideyuki Tokuda for the panel 
discussion on advanced reservation. The session chair raised a number of interesting 
questions and directed them at the panel. Tokuda asked if we really need advanced 
reservations. If so, what type of quality demanding services shall we use advanced 
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reservation for? How can we maintain reservation state and how would failure be 
handled? 

Steve Pink was unsure of the demand for advanced reservation services. State 
management of reservations looks troublesome since the models introduce a lot of 
state and require switches/routers with plenty of memory/storage to maintain it. Pink 
suggested that existing reservation architectures might be too complex for the 
network at the moment. Therefore, he proposed to separate control functions from 
packet forwarding. Pink also argued that RSVP is not the most appropriate choice for 
advanced reservations signaling. For RSVP to function properly, the senders should 
be present in advance. This cannot always be guaranteed for advanced reservation 
applications. Therefore, advanced reservations are a function of the management layer 
and not the packet-forwarding network. 

Lars Wolf summarized what he considered to be the open issues on the topic. These 
included the duration of reservation, stacks, failures, distribution of announcement 
information, management of resource and required protocol changes. The most 
challenging problems are state maintenance and failure handling. All systems 
performing advance reservation must keep the associated state information for 
potentially long periods of time. This must be stored in non-volatile memory to 
survive system shutdown. Wolf described this as the hard-state approach. 
Alternatively, similar to the approach followed by RSVP, the reservation may be 
refreshed from time-to-time - he called this the soft-state approach. Wolf believes 
advanced reservations could be useful for several application classes. However, 
advance reservation raises difficult questions that need to be resolved. 

4.8 QOS-based Transport Protocols 

Chair: Steven Pinky Swedish Institute of Computer Science 

Historically, transport protocols have been a hotly researched topic in computer 
networking. With the advent of multimedia, there has been a move away from 
designing reliable, high performance data transports to transports that support end-to- 
end QOS guarantees. This session consisted of two long and two short paper 
presentations on issues surrounding the development of QOS-based transport 
systems. 

Presentations 

The first paper presented by K. Fukuda [Fukuda,97], investigated QOS mapping 
issues between a user and a video transport system. Fukuda described a QOS mapping 
method between user preference for video quality and the required bandwidth to 
transport the resulting video flows. This work assumed that the underlying network is 
capable of supporting a bandwidth allocation mechanism such as deterministic bit rate 
service class in ATM, RSVP, IPv6, etc. Based on spatial, SNR and time resolutions 
QOS parameters, the QOS mapping function derives the required bandwidth to 
support MPEG-2. The mapping between QOS parameters and user perceived video 
quality is then calculated using classic mean opinion score evaluation testing. 
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Jean-Fran 9 ois Huard [Huard,97], Columbia University, reported on end-to-end QOS 
mapping. A simple mathematical formulation for mapping QOS parameters between 
application and transport was derived. A platform was developed for evaluating end- 
to-end QOS by performing concurrent network, transport and application level 
measurements. The loss bound empirically obtained under the assumption of 
uniformly distributed cell losses within a video frame is too conservative. Early 
results suggest that the existing literature on loss mapping is typically too 
conservative by a factor of three. Huard concluded that in order to obtain better 
empirical QOS mapping rules between the application, transport and network, more 
data needs to be collected and analyzed. 

Next, P. Conrad [Conrad,97], University of Delaware made the following position 
statement: ‘Transport QOS over Unreliable Networks: No Guarantees, No Free 
Lunch!”. The talk presented an approach to transport in unreliable networks, 
investigating trade offs between qualitative QOS parameters (e.g., order and 
reliability), and quantitative parameters (e.g., delay and throughput). Conrad focused 
on partially ordered and partially reliable transport services. The key results are that 
both sender-based and received-based reliability schemes for providing partial 
reliability achieve almost identical reliability and delay. On the other hand, a sender- 
based approach provides better throughput than a receiver-based approach at higher 
loss rates. 

In the final talk of this session, Glenford Mapp [Mapp,97] Olivetti & Oracle Research 
Lab, reported on development of a QOS-based transport protocol called Al. The 
transport was designed to provide QOS trade offs rather than strong guarantees. Mapp 
discussed the trade offs between qualitative QOS such as order and reliability and 
quantitative QOS such as delay and throughput. The transport service supported the 
notion of a QOS vector to specify all transport requirements at the API. Preliminary 
performance results for Al running over ATM were presented and compared with an 
efficient kernel implementation of TCP/IP. 

Panel Discussion 

In the panel discussion that followed, the Chair, Steve Pink initiated a discussion by 
making the observation that two opposing trends seem to be emerging within 
transport design. On one hand, as applications become increasingly sophisticated in 
their requirements, newer transport protocols should be developed to support the 
required functionality. On the other hand, it is argued that since only applications can 
truly understand their data semantics, traditional transport functions should be 
removed from the transport to the applications layer. Pink then solicited questions 
from the audience. 

A member of the audience asked that if trends were toward thinner and thinner 
transports then why have a transport layer in the first place? The panel's response to 
this question was mixed. Glenford Mapp agreed with this comment and was of the 
opinion that the transport in its traditional form was on its way out! Jean-Francois 
Huard, however, took a different line. In his opinion, the classical algorithms for 
providing reliable, flow-control and sequenced delivery are too complex to be left to 
the average application programmer. Pink agreed with this and noted that the recent 
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move toward multicast communications may redefine the role of current transport 
protocols. Here, the difficulty lies in providing scalable reliable multicast flows. 
Many of the well-understood techniques including positive acknowledgements do not 
work in this environment. 

Pink followed by leading a discussion on user versus kernel level transports. He noted 
that there are primarily two types of processing activity in any transport protocol: the 
more expensive per-byte processing for computing packet checksums and the less 
expensive per-packet processing for flow-control, acknowledgment, etc. The classic 
argument for kernel-level transport protocols has been to perform efficient per-byte 
processing. However, as network speeds increase to gigabits, it seems sensible to 
delegate much of this computer intensive functionality to specialized hardware. This 
leaves the task of per-packet level processing to software. The consensus among the 
panelists was that user-level transport implementations could be as efficient as kernel 
level implementations. This, plus the added flexibility of being able to decouple the 
transport from the operating system makes user-level transport protocols ideal for the 
increasingly specialized needs of today’s sophisticated applications. 

4.9 QOS Mapping 

Chair: Jean-Pierre Hubaux, EPFL 

QOS mapping performs the function of automatic translation between representations 
of QOS at different system levels (i.e., application, operating system, transport and 
network, etc.) and thus relieves the user of the necessity of thinking in terms of lower 
level specifications. This session included two long and two short papers that 
addressed the translation between application QOS specification, and the operating 
system and network QOS. 

Presentations 

In the first talk, N. Nishio [Nishio,97], Keio University, presented a simplified 
method for session coordination using a three-level QOS specification and translation 
scheme. It may be unrealistic to expect the application to specify its QOS 
requirements using operating system/network specific language, e.g., memory size in 
Kbytes or bandwidth in Mbps, etc. However, such information needs to be distilled 
from the application specification for admission control and resource reservation. To 
address this need, Nishio introduced a QOS architecture that presented the user-level 
specification in terms of application program QOS, middleware QOS, and system- 
level QOS. Nishio described a conductor/ performer paradigm used to handle the 
translation function between these system components. 

In the next presentation, H. Knoche [Knoche,97], University of Hamburg, reported 
on a quantitative QOS mapping approach. Knoche identified QOS mapping as the 
process of translating QOS parameter bounds from layer to layer and finally to 
specific resources. General mapping between video frame service data units and 
network quality requirements such as delay jitter, throughput and reliability were 
presented. QOS mapping took into account the cases of common service functions 
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such as segmentation/reassembly, blocking, playout buffer, interleaving, coding, or 
peak smoothing. 

Klara Nahrstedt [Kim,97], University of Illinois, Urbana-Champaign, presented an 
integrated view of QOS translation and admission control. Nidirstedt discussed a 
translation between the MPEG-2 video quality representation and the underlying 
operating system resource, namely the CPU. A conununications model was analyzed 
for different MPEG grouping schemes and communications paradigms. Nahrstedt 
conunented that a middleware level seemed like a natural point where the user can 
specify QOS requirements using application language and the operating 
system/network derives QOS parameters expressed in its own language. 

In the final paper of the session, Valerie Issarny [Issarny,97], INRIA, discussed the 
translation of QOS specifications in a QOS architecture. Issarny discussed the 
development of customized software architectures. These included the specification 
of execution properties such as interaction properties, which capture the 
conununication patterns, and QOS properties, which represent resource management 
policies implemented by middleware. The main challenge of QOS translation is to 
correctly specify the interaction and QOS properties so that a proper customization of 
the resulting QOS architecture may be provided. 

Panel Discussion 

Jean-Pierre Hubaux highlighted the layers between the application and 
operating/network for which QOS mapping was needed. He then posed a general 
question to the panel: given the diversity of application and underlying networks and 
operating systems, is it feasible to try to formulate a generic framework for QOS 
mapping and, if so, how far are we from it? The response from the panel was 
unanimous in that they believe that QOS mapping is an area that is just beginning to 
be understood. 

However, the reasons given by each member of the panel varied widely. Klara 
Narhstedt reasoned that any form of generic framework would have to be qualified 
given the diversity. The typical technique used today is through some form of 
application profile characterization. She believes that the whole field of QOS 
mapping is still in its infancy given that the scope of mapping considered in most 
schemes is still fairly simplistic and static in nature: focusing on a certain application, 
operating system and network. 

Another point raised by the floor was that most QOS mapping schemes address only 
continuous media services avoiding other conununications services, e.g., transactions. 
Hendrick Knoche felt that the primary difficulty in formulating good QOS mapping 
stems from the fact that we do not yet understand the perceptual effect of QOS. 
Nobuhiko Nishio noted that the interaction problem among the many layers in a 
system complicates the issue of QOS mapping since the dynamics are usually non- 
linear and difficult to characterize. 

Jim Van Loo, Sun Microsystems, asked the panel if there was a good abstraction or 
metaphor for expressing QOS mappings? This question cut to the heart of the 
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problem. Nobuhiko reflected that whatever the abstraction might be, it would likely 
be based on economic concepts and be closely indicative of the cost involved of 
rendering the service to be mapped. 

4.10 QOS Adaptation 

Chair: Klara Nahrstedt, University of Illinois at Urbana-Champaign 

Many distributed multimedia applications are adaptive in nature and exhibit flexibility 
in dealing with fluctuations in network conditions. QOS adaptation algorithms can, 
for example, trade temporal and spatial quality to available bandwidth or manipulate 
the playout time of continuous media in response to variations in delay. This session 
comprised two long and three short papers on the topic. 

Presentations 

In the first talk of the session, Pratyush Moghe [Moghe,97] Bell Labs, addressed what 
he described as “terminal QOS” for adaptive applications. Next generation terminals 
are expected to support sophisticated adaptive applications. Since some terminals 
have limited power (e.g., personal digital assistants and network computers), the 
application processing delay can be a significant component of end-to-end delay. 
Moghe call^ this the terminal QOS measure. Currently, each adaptive application 
has its native adaptation algorithm that operates independently of other applications, 
their adaptation algorithms, or scheduler. Moghe presented an analytical relationship 
between network feedback and the level of adaptation. This theoretical framework is 
useful in understanding the relationship and interaction between the adaptive 
application, end-system and network. The speaker concluded by saying that the 
notion of terminal QOS may be used to tune adaptation algorithms. 

Next, Dorgham Sisalem [Sisalem,97], GMD Focus, presented an approach for 
dynamically adjusting the sending rate of applications to the congestion level 
observed in the network. The speaker discussed how senders could increase their 
sending rate during lightly loaded situations and reduce it during overload periods. 
Sisalem presented results that illustrated the efficiency of a direct adjustment 
algorithm responding to fluctuations in available bandwidth while maintaining low 
loss rates. Currently, the work does not address the issue of fairness nor interaction 
between adaptive traffic, e.g., TCP. Sisalem concluded by indicating that adaptive 
schemes can suffer from fairness problems potentially causing starvation of reactive 
flows such as TCP. 

The third paper, by Max Ott [Ott,97], NEC, reported on adaptive QOS in multimedia 
systems. Ott made the point that most QOS architectures present QOS-aware APIs to 
the applications. This is either achieved by adding QOS parameters to standard 
system calls, or by raising the system abstraction to a higher level, filling the gap with 
what is often referred to as middleware. The speaker reflected that in either case there 
seems to be a serious desire to draw a strict line between “us”, the QOS provider, and 
“them” the elusive application. Ott argued that it seemed natural to define an 
architecture that allows the introduction of QOS at any level: from the CPU and 
network resources to the user’s “satisfaction”. He reported on an architecture that has 
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evolved over the past few years at NEC that has introduced the concept of QOS 
adaptation at each level of the architecture. QOS is specified by contracts that are 
established between clients and service providers using a single generic 
programmable API. 

Oh [Oh, 97], Osaka University, presented the next paper on a dynamic QOS 
adaptation mechanism for a networked virtual reality system. The motivation behind 
the work is to maintain acceptable user presentation quality when resources fluctuate 
in a networked virtual reality system. Oh introduced the notion of “importance of 
presence” which when applied to objects in a virtual reality system can be used to 
trade off available resources and objects. Importance of presence is based on the 
maximum visible distance and angle of incidence between the users and an object in 
the user’s virtual space. The speaker discussed an adaptive algorithm that reduced the 
QOS of an object based on its importance of presence indication. At the end of his 
presentation the speaker demonstrated the technique using a videotape of the 
networked virtual reality system using adaptation based on the importance of 
presence. 

In the final talk of this session Dan Revel [Revel,97], Oregon Graduate Institute of 
Science and Technology, discussed predictable file access latency for multimedia. 
The speaker asserted that multimedia applications are sensitive to 10 latency and jitter 
when accessing data from secondary storage. To address this challenge. Revel 
introduced the concept of transparent adaptive prefetching which uses software 
feedback to provide multimedia applications with file system QOS guarantees: 
predictable low-latency access to data on secondary storage. The research at Oregon 
Graduate Institute is strongly focused on adaptive software feedback algorithms for 
Internet video, mobile systems and adaptive QOS access to storage. Currently, the 
QOS interface to transparent adaptive prefetching allows applications to express 
adaptive needs in a vocabulary that is meaningful to them. 

Panel Discussion 

Klara Nahrstedt conunented that QOS adaptation techniques, while complex in nature 
help to efficiently share resources in the end-systems and network for a class of 
applications that can accommodate varying resource availability. Nahrstedt followed 
up by asking the panel whether they now considered QOS adaptation as a 
replacement for reservation? A wide variety of opinions were articulated. Dorgham 
Sisalem used TCP as an example to argue that TCP’s congestion adaptation 
mechanisms did very well without any explicit call setup and resource reservation; 
therefore why is reservation needed? 

Max Ott argued that if strong QOS guarantees were required (e.g., timing guarantees) 
then reservation was unavoidable. Nahrstedt said that QOS adaptation filled the 
middle ground providing a poor person’s QOS guarantee. Pratyush Moghe thought 
that many continuous media applications could operate at a minimum level guarantee 
and use QOS adaptation techniques to achieve better quality when additional 
resources became available. Such a hybrid approach grew out of the consensus that 
many applications can not degrade below a certain level. 
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5. Workshop Panels 

The workshop included two panels. The first panel [Schmidt, 97] looked at the 
emerging field of QOS in distributed object computing environments. The second 
panel [Schulzrinne,97] highlighted some of the concerns researchers have about a 
reservation driven Internet. 

5.1 QOS for Distributed Object Computing Middleware: Fact or 
Fiction? 

Chair and Organizer: Douglas C. Schmidt, Washington University 

Panelists: Max Ott, NEC, Guru Parulkar, Washington U., RolfStadler, Columbia U., 

Andreas Vogel, Visigenic 

The panel discussion started with a statement by the Chair suggesting that nobody 
uses distributed middleware with QOS support, therefore, do we really need such a 
layer? If yes, what does QOS-based middleware look like? Is QOS-based distributed 
middleware a fact or a fiction? Currently, it is a fiction since no such product or 
public domain platform exists. It will become a fact when researchers and developer 
are using QOS-based middleware as they do C++ or JAVA. Clearly, we need to ask 
ourselves what does such a middleware bring? Yet another layer? 

The panel argued that distributed object computing was essential for architecturing 
complex software systems, ease of programmability and interworking across 
heterogeneous systems. A number of research groups are building real-time ORBs 
and exposing QOS at the API for user programmability. Freeware is becoming 
available (e.g., Glenford Mapp, Olivetti & Oracle Research Lab, announced that ORL 
had put their ORB 2.0 on the web). Andreas Vogel stressed that real-time CORBA 
products will become a reality when there is demand from the customer. When the 
demand transpires the industry would react positively. 

A member of the audience asked why CORBA has become the common language, 
ORB of choice and subject of this panel? Guru Parulkar pointed out that CORBA is 
an existing standard and has been widely implemented by multiple vendors. It has a 
number of deficiencies, he asserted, many ORB implementations are not highly 
efficient and support of QOS is missing. However, Guru Parulkar felt optimistic that 
these issues could be amended and were not “show stoppers”. 

Each of the panelists provided a list of open issues which they believed must be 
addressed before QOS-based middleware became a reality: 

• Schmidt maintained that the ORB needed a real-time capability and middleware, 
such as CORBA, is being modified to incorporate such a feature; 



• Ott argued that any emerging platform needs to take seriously the user 
perspective to middleware to ease programmability and simplify QOS abstractions; 
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• Parulkar stressed that we need to fix CORBA to support QOS in the end-system 
and at the network access points in order to provide service guarantees at the I/O 
level, appropriate packet and process scheduling was needed; 

• Stadler remained upbeat about the use of the technology in the network arguing 
for distributed interactive resource controllers with global control to deliver services 
with a minimal set of guarantees and, in case of higher quality, they should support 
adaptive behaviors; 

• Vogel reflected that ORB vendors (e.g., Visigenic) will eventually incorporate 
new CORBA services and QOS bindings for multimedia streams and control when 
the market demands it. He predicted that it would happen soon. 

Toward the end of the session questions of whether ORBs should explicitly support 
multimedia streaming were raised. There was clear disagreement about this issue. The 
question is whether the ORB is used to set up streams and then moves out of the way 
or, conversely, it can explicitly support isochronous communications via RPC. Some 
panelists stated that this should not be part of CORBA. Others argued that for 
continuity the ORB should support streaming. Andreas Vogel mentioned that OMG 
would not support streaming through the ORB. 

5.2 Reservations about Reservations 

Chair and Organizer: Henning Schulzrinne, Columbia University 

Panelists: Fred Baker, CISCO, Andrew T. Campbell, Columbia U., Jon Crowcroft, 

UCL, Roch Guerin, IBM and Dilip Kandlur, IBM 

The panel discussed the current state and future developments of QOS support in an 
Internet and the impact of a reservation driven network. Each member of the panel 
started off by presenting a short position statement of their vision on the rollout of 
QOS in the Internet. This was followed by heated debate on concerns about 
reservations. 

Fred Baker, Cisco, stated that QOS routing, line protocols and queue management can 
improve QOS. He emphasized that for queuing, congestion management algorithms, 
such as weighted fair queuing, serve as good tools for low speed links when there is a 
limited number of flows. However, on the average OC-3 link where there are 
hundreds and thousands of simultaneous flows (e.g., in a backbone network), 
statistical approaches like random early detection prove to be very useful. In this case, 
the binding is based on IP precedence. This precedence level can be set either by a 
traffic originator or via administrative controls in the routers. However, like random 
early detection, being a FIFO queueing algorithm, is not predictable and is not 
deterministic since it depends on host behavior. Moreover, it is also dependent on 
bulk of traffic being TCP. Besides these approaches. Baker suggested that RSVP is a 
reasonable answer to QOS-enhanced traffic, particularly for edge networks and large 
flows. 

Next, Roch Guerin, IBM, asked what the driving force behind reservations was. He 
mentioned that there is currently no application that is so critical that it can only 
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function by making reservations. Alternatively, there are so many of these 
applications that it is impossible to define a generic reservation framework to satisfy 
them all. Guerin argued that the main drivers for reservations are the economic and 
contractual factors. As the Internet is moving towards a commercial network, people 
would like to know what they are paying for - and ISP’s also need a pricing model. 
This requires enforceable and observable service contracts. These contracts should be 
simple and deterministic to avoid adding additional complexity to the infrastructure. 
Guerin also pointed out that there are many conflicting forces to economic factors 
such as the cost of resources and their exploitation. In particular, cheap resources lead 
to simple signaling, where value is added at end-systems. In contrast, if resources 
remain expensive, a network will need complex signaling, thus leading to providers 
and equipment vendors adding most of the value. 

Dilip Kandlur, IBM, expressed some reservations about RSVP scalability. He 
cautioned that RSVP is able to scale to a large number of receivers in a session, but 
not a large number of unicast sessions. He provided possible solutions to achieving 
the latter, which included aggregation of sessions, flow state management and path 
management. 

Henning Schulzrinne, Columbia University, discussed several points: the need for a 
basic service with call admission control; at what point is reservation the best option; 
flow aggregation and RSVP issues. The existing consumer ISP model is based on a 
multiplexing model that supports 200-300 concurrent users with 10-15 customers 
sharing an ISP line. With Internet telephony, radio-like services and content pushing 
such a model is not sustainable. This implies that volume-based charging is required 
rather than reservations. Schulzrinne mentioned that reservations are still necessary 
for guaranteeing special purpose QOS, for services that cannot tolerate disruption. 
RSVP as a reservation protocol for the Internet introduces unnecessary complications 
such as flow merging, delay guarantees and receiver diversity. 

The fourth presentation in this panel session focused on the use of a simple approach 
to QOS provisioning. Jon Crowcroft had arranged to come in live over the Internet. 
However, moments before the panel was to begin, UCL experienced a complete 
brown out and Jon Crowcroft was source squenched! Andrew Campbell stepped in to 
present the main points of Crowcroft’ s position. Crowcroft suggested that there were 
three simple choices - each with their pros and cons: 

• over-engineering selected paths, where a particular route could be over 
provisioned. Such a route might be shared by multiple networks as well as users, 
hosts or applications; 

• subscription for selected terminals or addresses, where a virtual private Internet 
offering improved QOS can be created by assigning resources based on address 
prefixes or IP network numbers; and 

• on demand service, where a virtual circuit is set up using a signaling protocol, 
call admission control, traffic policing, traffic accounting, and service discrimination 
through scheduling. 
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Crowcroft preferred the first choice of over-engineering selected paths but cautioned 
that it might be difficult to support new services due to such an over-simplistic view 
of resources. However, his contention was that the cost of providing new services 
outweighs the benefit. The balance, he suggested, should be redressed toward simpler 
end of the QOS provisioning spectrum: that is, over-engineered selected paths. 

Andrew Campbell presented his own reservations about reservations, pointing out 
that both ATM and RSVP signaling are too heavy weight and complex. He also 
revealed his concerns about scalability and stability of RSVP as a widely deployed 
signaling system for the Internet. Out-of-band signaling systems, he asserted, need to 
be sized, engineered and their stability thoroughly investigated. 

The presentations sparked off an interesting debate on reservations about reservations. 
The panelists seem to agree that reservations are at times inappropriate. Guerin, who 
is less comfortable with the need for reservations, felt that reservations would only 
add complexity in the end. 

6. QOS: Where are we? 

IWQOS^97 Invited Workshop Paper: by Ralf Steinmetz and Lars Wolf, Darmstadt 
University 

Lars Wolf [Steinmetz,97] presented the invited workshop paper on the topic of “QOS: 
Where are we?”. He began with an overview of terminology, issues and trends in the 
provisioning of QOS concentrating on QOS principles and the architectural issues 
addressed by a number of research groups and standards bodies (e.g., lETF’s int-serv 
work). Wolf reflected that over the past several years, QOS has evolved as a major 
field of research to support new applications such as real-time distributed multimedia 
applications, which very often are based on networked computer systems. These 
applications require time-dependent data processing and place huge processing 
demands on distributed computer systems. 

The goal of QOS architecture is to ensure the overall presentation of multimedia data 
with respect to the end-to-end QOS requirements of applications. Because QOS is 
end-to-end, he argued, end-systems, servers, networks, system software and 
applications must handle the data accordingly. QOS model generally have a number 
of components/viewpoints (e.g., user, application, system and network QOS) which 
address various approaches to QOS provisioning, both pessimistically (e.g., worst- 
case assumptions based on peak rate resource allocation) and/or optimistically (e.g., 
resource reservation and adaptive mechanisms). Among the optimistic approaches, 
resource reservation is preferred since adaptive methods like media scaling and 
filtering cannot offer hard QOS. 

Wolf proceeded to describe the fundamental steps in provisioning QOS in the end- 
system and network based on signaling, resource reservation and scheduling 
mechanisms. These steps can be divided into the QOS negotiation phase (including 
QOS specification, capacity testing and QOS calculation, resource reservation) and 
the data transmission phase, where the negotiated QOS is enforced by appropriate 
resource scheduling mechanisms. Several resource management components need to 




Workshop Summary 



xxxvii 



interact to provide end-to-end assurances: applications, QOS translators, admission 
controllers, resource schedulers and resource monitors. Resource reservation 
protocols serve as a means to transfer information about reservations and to 
participate in the negotiation of QOS values. 

7. Closing Remarks 

Andrew Campbell provided the closing remarks. He announced that the next 
workshop would be held in Napa Valley, California in May 1998 and would be 
hosted by Ed Knightly from Rice University and Rich Friedrich from HP Labs. 

The theme of IWQOS’97 - building QOS into distributed systems - begs the question: 
in today's world is QOS a fact or a fiction? For those that attended the workshop, with 
its excellent technical sessions and panels, it is indeed, a fact. During the three day 
meeting, participants had heard reports about actual implementation results and more 
speculative work. While this looks very promising, some practitioners have 
reservations about QOS research. Perhaps, this was best typified during the panel on 
reservations about reservations. The catchy title of the panel captures that feeling of 
concern. For example, the entire reservations panel agreed that it was very unlikely 
that a single approach (e.g., RSVP) would fit all applications, with different trade offs 
between complexity, level of guarantees and scaling issues. 

Returning to the theme of whether QOS was a fact or fiction, Campbell asserted that 
QOS is fiction in the sense that it is not a concrete fixture in our lives, e.g., no 
network exists today that lets the user configure QOS on-demand. So how long do we 
have to wait until fiction becomes fact? Campbell concluded by telling the audience 
to “stay tuned” for Napa ’98. 

For details on IWQOS’98, Napa Valley, see: 

• http: //www-ece. rice.edu/conf/iwqos98/ 
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Abstract 

The recent move towards market deregulation and open competition has sparked a wave of 
serious introspection in the telecommunications service industry. Telecom providers and opera- 
tors are now required to open up their primary revenue channels to competing industries. In this 
paper, we examine the service structure of two major global communication networks - the 
Telephone Network and the Internet and explore their weaknesses and strengths. 

Building upon the experience we gained during the development of the initial xbind proto- 
types, we discuss the realization of an open programable networking environment based on a 
new service architecture for advanced telecommunication services. Our approach to the prob- 
lem stems from two angles - one conceptual, the other implementational. 

In the first, we attempt to develop a service model that is open and reflects the economic market 
structure of the future telecommunications service industry. We believe that investigating such 
a model will help clarify some of the pertinent issues confronting the telecommunications ser- 
vice industry today as it comes of age. An engineering model for realizing the service market 
model is proposed as a vehicle for creating multimedia services on broadband networks. In the 
second, we investigate the feasibility of engineering this model from an implementation stand- 
point. We address some of the important issues fully aware that our work has opened new vis- 
tas that call for additional research. 

We believe that our work will lead to a major shift of paradigm in research and development of 
service architectures for telecommunication networks. It has already found strong resonance 
with the members of the OPENSIG international working group and its foundations have been 
proposed for possible standardization by Nortel. 

1. INTRODUCTION 

The ability to rapidly create and deploy new and novel services in response to market 
demands will be the key factor in determining the success of the future service 
provider. As the high speed switching and communication infrastructure improve and 
bandwidth becomes a commodity, it is envisioned that the competition for product 
differentiation will increasingly depend on the level of sophistication, degree of 
flexibility and speed of deployment of services that a future provider can offer [31]. 
These factors in turn depend heavily on the flexibility of the software architecture in 
place in a provider’s operational infrastructure. 

The current generation of telecommunication networks is based on an architecture 
over 30 years in age [18]. The basic tenet behind the architecture is the implicit 
assumption that Customer Premises Equipment (CPE) has no computational 
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capabilities and limited modes of interaction. This assumption eventually translated 
into a design somewhat akin to a mainframe cluster model where a small number of 
computationally powerful processors called Service Control Points (SCPs) are 
distributed throughout the network and take on the responsibility of service 
provisioning for all connected CPEs. As in the mainframe cluster model, the CPEs 
themselves act solely as the user interface channelling simple user requests and 
responses into the system. Within the network, dedicated processors running 
specialized monolithic software optimized for efficiency process, co-ordinate and 
translate these requests and responses into the necessary data and connections that 
constitute the service. 

The primary deficiency of this architecture is its monolithic view of the service 
provisioning process. The network operator assumes almost complete control over the 
decisions pertaining to the design, introduction and management of services since it 
owns the SCPs. Interfaces to the service management infrastructure are often non- 
existent, proprietary or narrow in scope and intimately coupled to the hardware they 
operate on. As a result, any third-party involvement in service programming is limited 
to customizing only a small set of operational parameters. Furthermore deploying new 
services in today’s telephone networks takes up to several years primarily because the 
software systems with which they need to be integrated are enormously complex and 
prone to many cross-service interactions. 

Ironically on the other hand, the capabilities of the modern computer has advanced 
well beyond the stifling limitations imposed by these early architectures. Modern 
software engineering has advanced to the point where industry standards [29] now 
exist for implementing platform independent distributed component based software. 
These and newer emerging standards allow the construction and packaging of 
independent software components into suites which can further be assembled via 
application-level frameworks to create a truly distributed information infrastructure on 
a global scale. While these modem software engineering aids by themselves do not 
solve the fundamental problems inherent in any scalable distributed system, they do 
provide an excellent infrastructure for dealing with problems of programmability, 
portability, maintainability and reusability, problems frequently faced by the 
teleconununications software industry. 

Recent advances in distributed systems and transportable software together with 
increasing demand for better control of QOS in multiservice networks are driving a re- 
examination of network software architectures. A new opportunity exists to reconcile 
the perspectives of the computing and communication communities in new network 
architectures that support service creation, QOS control, and the joint allocation of 
computing and communications resources. 

Since the Fall of 1994 we have been experimenting with a first generation broadband 
kernel called xbind [20], [26]. The broadband kernel is a programmable operating 
platform that supports the creation, deployment and management of networked 
multimedia services (e.g., virtual circuits, virtual paths, virtual networks, multicast, 
etc.) and mechanisms for efficient resource allocation (e.g., connection management, 
route management, admission control, QOS mapping, etc.) . The term ‘kernel’ is 
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deliberately used to draw a parallel between its role as a resource allocator and 
extended machine, and that of a typical operating system. The broadband kernel 
behaves as a resource allocator because it mediates and arbitrates between conflicting 
requests for resources made by various parties in the system. It functions like an 
extended machine because it provides a simplified means of accessing fundamental 
system services by abstracting away the operational complexities of provisioning these 
services. 

Building upon the experience we gained during the development of the initial xbind 
prototypes [10], [26], we discuss the realization of an open programmable networking 
environment based on a new service architecture for advanced telecommunication 
services. Our approach to the problem stems from two angles - one conceptual, the 
other implementational. In the first, we attempt to develop a service model that is open 
and reflects the economic market structure of the future telecommunications service 
industry. We believe such a model will help clarify some of the pertinent issues 
plaguing the telecommunications service industry today as it comes of age. In the 
second, we investigate the feasibility of engineering this model from an 
implementation standpoint. We address some of the important issues fiilly aware that 
our work has opened new vistas that call for additional research. 

We begin in Section 2 by proposing a simple classification scheme for services. We 
use this scheme to examine the service structure of two prominent networks - the 
Telephone Network and the Internet. In Section 3, we introduce the basis of an 
economic model for describing future telecommunication services based on market 
forces. We believe this will be the end result of a natural evolution of the industry given 
the current trends in deregulation and open competition. In Section 4 we propose a 
service architecture based on the principles of open APIs that closely parallels our 
economic model and briefly list out some of its principle components. In section 5 we 
present the service creation model. Quality of service, performance and scaling issues 
are dealt with in section 6. Implementation considerations are presented in section 7. 

2. SERVICE ARCHITECTURES: A TAXONOMY OF THE STATE-OF- 
THE-ART 

A service architecture defines the structure and mode of operation of a facility that 
offers a service. There are two basic services in most communication infrastructures: 

1. Basic Communication Services, which focus on the mechanisms and the interac- 
tions between network entities so as to enable the basic communication process; 
and 

2. Content Services, which focus on the means of access, presentation and organiza- 
tion of content resources in the network to facilitate communication. 

A third category of services deals with value-added enhancements over the basic 
communication services. Conceptually these services lie between the two basic 
categories in the sense that their utility is dependent on the functioning of the basic 
communication service yet by themselves are not considered as such. These services 
are exemplified by the Advanced Intelligent Network (AIN) [8] services and range 




6 



Keynote Address 



from convenience features like call forwarding and caller ID, to more complex services 
like mass calling. 

2.1. Service Requirements - the Need for Domains 

The conflicting forces of market demand for both flexibility, accountability and 
robustness makes the task of architecting an open service model a difficult technical 
challenge. Basic communication services lie at the base of the service spectrum 
supporting the fundamental mechanism for information exchange upon which the 
other service categories are derived. Thus, the primary requirement of basic 
communication services is one of robustness, high availability and low failure rate. 
Content services, on the other hand lie at the opposite end of the spectrum. Market 
forces demand these to be highly customized, user oriented and easy to deploy. 

Hence, as we ascend the hierarchy of services from the basic communication services 
to sophisticated content-driven end-user services, the need for programmability also 
rises. The difference in requirements for these service categories often result in 
different technical solutions being employed for addressing the issues pertinent to each 
category. In effect these enforce a natural domain-like separation between network 
concerns, service concerns and user concerns. A similar view is reflected in the 
Telecommunications Information Networking Architecture Consortium (TINAC) 
stakeholder domains [6] which classify TINAC services into network provider 
domains, service provider domains and user domains. 

2.2. Service Models - a Question of APIs? 

The service architectures of the Internet and the Telephone Network differ in several 
aspects. In the Telephone Network, historical assumptions about CPE capabilities has 
led to a two tiered architecture consisting of a user domain and a network domain. (The 
service architecture of ATM Networks is closely related to the one of the Telephone 
Network.) Users lie at the periphery of the system and access network services via a 
thin interface known as the User Network Interface (UNI) [9] while within the network 
domain, interconnection is achieved via a complex Network-Node-Interface (NNI), In 
this model, there is little distinction between network provider and service provider 
since most useful services (in particular, IN types) require the intimate network support 
available only through an NNI. In this sense, although there is a clear separation 
between bearer services and AIN services in a technical and engineering sense, in 
reality until only recently, the administrative, operational and business concerns of an 
enterprise often make it more lucrative to merge network and service provider roles as 
one. For instance, in the past, protective regulatory structures had always afforded 
network operators the luxury of using AIN services as a value-added component to 
enhance the marketing and sales of plain old bearer services. 

The recent 1996 Telecommunications Act however, has demolished to a considerable 
extent many of these protectionistic measures, paving the way for freer competition at 
all levels in the market. One of the more significant changes mandated by the new 
regulations effectively require that network operators provably demonstrate capability 
to support third party service provisioning. These and other emerging trends are 
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indicative of the need for a serious re-examination of current telecommunication 
service models (and the ensuing business practices) or risk serious financial 
consequences. 

The intimate coupling of the communications and service architecture makes the 
introduction of new services, particularly those that do not conform to the traditional 
point-to-point connection paradigms clumsy and restrictive because: 

1 . The interface between the network and the service implementor (which is respon- 
sible for basic communication services like connection setup procedures) is rig- 
idly defined and cannot be replaced, modified nor supplemented - all services 
must be implemented in terms of these. 

2. The interface between individual services is defined by the rather restrictive 
Intelligent Network Access Point (INAP) protocol which all conceivable service- 
level signalling procedures and semantics must map into. 

An even worst situation presents itself if we examine the boundary between the 
network and the user. The potential diversity and flexibility requirements of user level 
services and applications far exceed that of typical AIN services demanding all the 
more an open environment for design, installation and operation. The simple UNI is 
not extendible and was never designed for these requirements. 

In the Internet, the lack of a UNI implies a conceptually flat service structure where 
there is no strict distinction between network provider, content provider and user [7]. 
In practice domain-like separation (usually for security and administrative reasons) is 
typically imposed through artificial means (like addressing structure and naming). In 
this model, any user can also be: 

1. A network provider by achieving physical connectivity with the Internet and 
offering connectivity services to other users. 

2. A content provider by making available content for public access and advertising 
its availability through a directory service. 

In terms of APIs for content provisioning, the Internet far excels the Telephone or 
ATM Networks. The Java virtual machine [29] in effect can be seen as a freely 
extendible API for content services whose basic parameters are programs instead of 
simple types. Even at the basic communication services level, IP options provide, in 
principle, a primitive API for influencing basic packet routing policies. In reality, most 
of these APIs are usually not fully implemented or supported. For example, the source- 
routing option of IPv4 is an example of an API which, if fully supported by all IP- 
capable hosts, would provide elegant solution to the problem of host mobility without 
the need for tunnelling. 

In summary, the service model of the Telephone and ATM Networks is one of provider 
and customer. This is a clear demarcation in terms of the technology employed (as 
reflected by the APIs) and responsibility between the two distinct roles. In the Internet 
this distinction is less clear and a peer-to-peer model is perhaps a more accurate 
analogy since users and providers both run on essentially the same technology. The 
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obvious advantage of a peer-to-peer service model is one of flexibility since there are 
no technical barriers from preventing any user from setting up his/her own service. On 
the downside, security, policy and standards are harder to enforce since they require 
cooperation from a much larger community. 

3. MOVING BEYOND THE STATE-OF-ART: A LAYERED MARKET 
MODEL 

In the previous section, we examined two primary service models and their respective 
trade-offs. We note that a key factor influencing the service model of a network 
depends to a large extent on the types and levels of APIs available. In fact, we believe 
that APIs primarily reflect the flexibility and maturity of a service architecture and 
good APIs at the service level are the macroscopic counterparts of good coding 
practices at the implementation level. 

In this section, we propose a 3 layered API based service model inspired by the 
principle of the open market which we believe better reflects the operating structure of 
the future communication services industry. The basic tenet of the model is the premise 
that the future telecommunication service industry will operate within an open market 
where sufficient alternatives exist to allow services to be traded as commodities. This 
premise is not unreasonable given the recent trend towards deregulation and the 
general move towards streamlined horizontal market structures. 

The model is divided into 3 layers with each layer representing a market. At the lowest 
layer, is a hardware market where numerous equipment manufacturers and vendors 
offer hardware and firmware solutions for building the basic communication 
infrastructure. The customers of this market are typically network carriers, third party 
software developers who specialize in developing software for service providers and a 
handful of service providers themselves. The APIs provided by vendors in this market 
allow their users to write basic communication services and the associated middleware 
components. In the second layer is a middleware service market where carriers, 
software developers and middleware service providers offer middleware service 
products to customers who are in the user service provisioning business. The APIs 
provided in this market are sufficiently high to allow development of any consumer 
level service. Finally at the highest layer is the consumer services market where 
consumer service providers compete to bundle, integrate and customize their wares in 
the most appealing form for the mass market. Within each market there may exist 
brokers (as rightly recognized by the TINAC stakeholder domain model [30]) whose 
role is to mediate dealings between buyers and sellers who, because of regulatory or 
business policies, cannot transact directly. The model is shown in Figure 1. 

The service model just described falls somewhere between the Internet’s peer-to-peer 
model and the Telephone Network’s strict provider-customer model. It allows, in 
principle, the cooperation of any number of entities in the network for realizing a 
conunon service as well as the competition among services for network resources. As 
will be shown in the next section, the corresponding engineering model can be 
parametrized in such a way that the basic characteristics of the peer to peer model as 
well as the characteristics of the provider and costumer model can be recovered. 
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Within each layer (or market), players are free to enter and buy, sell or rebundle each 
other’s services. Across layers, the relationship takes on more of the form of provider- 
customer. Once again, APIs play the crucial role of defining market boundaries. 
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Fig. 1. The Layered Market Model 



4. REALIZING THE SERVICE MARKETPLACE 

The layered market model outlined in the previous section is merely an economic 
model reflecting the author’s vision of the future telecommunications service industry. 
In the remaining sections of this paper, we focus on designing and realizing a novel 
service architecture in the technical sense which closely reflects the philosophy of the 
layered market model. The architecture we describe is targeted towards multimedia 
services as opposed to the economics of the general market model just presented. We 
begin by briefly describing the Extended Reference Model (XRM) [17] for multimedia 
networks and its decomposition into 3 submodels [20]. 

4.1. The Extended Reference Model 

The XRM models the communications architecture of networking and multimedia 
computing platforms. It consists of 3 components called, the Broadband Network (the 
R-model), the Multimedia Network (the G-model) and the Services and Applications 
Network (the B-model, see Figure!). The broadband network is defined as the 
physical network that consists of switching and communication equipment and 
multimedia end-devices. Upon this physical infrastructure, resides the multimedia 
network whose primary function is to provide the middleware support needed to 
realize services with end-to-end QOS guarantees over the physical media-unaware 
network. This is achieved by deriving from the broadband network a set of QOS 
abstractions. The latter jointly define the resource management and control space. 

The process of service creation calls for resource reservation and distributed state 
manipulation algorithms. From this perspective, the multimedia network provides a 
programming model that allows service behavior to be specified and executed. Service 
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abstractions represent the states of a service created using algorithms native to the 
multimedia network. These abstractions are used by the services and applications 
network for managing and creating new services through dynamic composition and 
binding. 



B 



G 



R 




Fig. 2. Overview of the RGB decomposition of the XRM 



4.2. The Power of APIs in the XRM 

As was mentioned previously, the functionality and indeed the level of sophistication 
of a service architecture is chiefly characterized by the APIs it offers. In the XRM, 2 
types of APIs are available for building services. These are represented by QOS and 
service abstractions that lie at the interfaces between the R- and G- (also denoted RUG), 
and G- and B-models (GIIB), respectively. 

The primary power of these APIs is the tremendous flexibility available for service 
providers and users alike to mold the structure of the network in a way that reflects 
economic policies and business practices. By this we mean that these various levels of 
APIs allow different parties or stakeholders to influence the partitioning of resources 
to carve out natural market niches or even create wholly new markets. In other words, 
unlike the service architectures of the Telephone Network or the Internet which tend 
to fall along the lines of ‘all or nothing’, we envision a future service marketplace to 
be rich in choices, variations and sophistication. 

RWG Interface APIs: QOS Abstractions 

RUG interface APIs abstract the states of local multimedia resources (both logical and 
physical) in the broadband network. These resources represent the devices, switches, 
links, processors and their respective capacities. Resources representing name spaces 
(e.g., VPA^C Identifiers) are also modeled. In the XRM, RUG interface APIs are 
implemented as a collection of distributed autonomous software entities with open 
interfaces. The open interfaces allow the states of these resources to be monitored. 
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controlled and managed remotely. More importantly, they allow these resources to be 
treated as independent pluggable components and services to be built by cleverly 
interconnecting combinations of them. 

From the perspective of the G-model, the RUG QOS abstractions appear as a collection 
of interfaces called the Binding Interface Base (BIB) [19]. Because the APIs in the BIB 
are seen as basic building blocks of a multimedia network, they are key to several 
important new initiatives including open signalling (see OPENSIG [25]) and 
multimedia integration frameworks (such as DMIF: http://drogo.cselt.it/mpeg/ 
mpeg.htm). 

We have recently announced completion of the draft specification of the BIB [1] at the 
OPENSIG workshop in Cambridge. The draft document and associated IDL templates 
have been made available to the conununity for conunents and improvement. Also at 
the recent ISO MPEG meeting at Bristol, a proposal for using the BIB as an interface 
framework for the “DMIF Network and Media Dependent Parts” has been put forward 
by Nortel [3], [4]. It is expected that this work along with the rest of the MPEG-4 
standards will reach international standard status by 1999. 

GWB Interface APIs: Service Abstractions 

In contrast to the RUG interface APIs, the G-model APIs provide access to the basic 
resource allocation and management algorithms of the multimedia network. These 
include algorithms for: 

1 . Communication services such as connection management, routing and admission 
control. 

2. Device management services. 

3. Transport level services such transport monitoring, protocol stack management. 

4. QOS mapping services. 

These algorithms operate on the BIB with the goal of implementing a set of 
rudimentary communication services that allow the creation of simple point-to-point 
connectivity with guaranteed service characteristics. Collectively, these services are 
termed the Broadband Kernel Services and are likened to be networking counterparts 
of low-level operating system services (e.g., memory management, file system 
management, etc.). 

In a similar manner that BIB interfaces are assembled to create broadband kernel 
services, broadband kernel services can themselves be assembled together to compose 
even higher level services. An especially useful class of such services are Network 
Services which consists of: 

1 . Virtual Circuit Services 

2. Virtual Path Services 

3. Virtual Network Services 

4. Multicast Services 
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These services allow the construction of complex connectivity graphs in the network 
with associated transport and management facilities. The collection of network 
services at the GIIB interface is known as the Service Interface Base (SIB). Similar in 
concept to the BIB, the SIB defines a set of independent interworkable services that 
may be assembled to create yet higher consumer level services. 

In the fall of 1996, we completed an implementation of the broadband kernel called 
xbind 2.0 [10]. The system supports a simplified BIB, prototypes of all broadband 
kernel services and a simple teleconferencing service with QOS renegotiation 
capabilities. 

The system has been installed on a testbed of 4 ATM switches and interconnects the 
Columbia University distance learning program, the Columbia Video Network, to a 
wide area ATM testbed. In terms of platforms, xbind 2.0 has been ported to SunOS, 
Solaris, HP-UX and Windows 95/NT operating systems and Fore ASXlOO/200, NEC 
Model 5 and ATML Virata 1 switches. The system also supports multimedia devices 
ranging from high-end workstation based JPEG video cards to entry-level real-time 
MPEG-1 encoders on the PC. xbind 2.0, which is CORBA 2.0 compliant [23], [24], 
stands at roughly 30,000 lines of C++ and Java code. Access to the switch hardware 
has been obtained through cooperative agreements with the vendors. 

5. THE SERVICE CREATION MODEL 

In accordance with the model described in the previous section, network services are 
obtained by invoking distributed algorithms in the space created by the BIB objects. 
For an object oriented software implementation this requires modeling the service 
interfaces as well as providing a service creation model. Both will be described next. 

5.1. Modeling Service Interfaces 

High level services (and conceptually all services) are composed of an algorithmic 
component and a data component. The algorithmic component expresses the execution 
logic of the service instance while the data portion is an abstraction of its state. In order 
for services to interact with each other, several types of service interfaces are also 
defined. These interfaces reflect the roles that a service might play in the process of its 
execution. Typically these include creation, operation, management and programming. 

The service creation interface is akin a constructor of a class [21]. It is the primary 
entry point of execution or instantiation of a service and is called by the server once 
the service template has been completely downloaded. The service operation interface 
defines the operational functionality of the service and is usually the primary interface 
through which services interact. The programming interface allows manipulation of 
the service logic to be performed while a service is in execution. Finally the service 
management interface allows for monitoring of service states and manipulation of 
service parameters. Figure 3 illustrates. 

Recall from the previous section that the service creation process typically requires 
support for a number of middleware services. The bubble in Figure 3 represents their 
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invocation points embedded in the service script. 




Service Management 



Fig. 3. Interfaces for a G- model multimedia service 



Although there might exist services with little or no state, the focus of our work is on 
those that require state keeping since these are typically more complex and harder to 
scale. Service states exist in two forms: 

1. Local states - which are of purely local significance 

2. Distributed states - which are states associated with other services and may be 
geographically dispersed. 

An example of a local state for a teleconference service might be the number of current 
users while a distributed state might be the list of all switches through which a 
conference connection passes through. 

Because most multimedia services usually require the assistance of one or more 
broadband kernel services, the state space of the service is usually distributed. 
Conceptually, distributed states can be viewed as a general directed graph where the 
nodes represent constituent ‘sub’-states and links represent the relation or nature of the 
association between nodes. 

5.2. The Process of Service Creation: A Simple Example 

The service creation process in broadband networks includes the creation of a service 
skeleton for an application, the mapping of the skeleton into the appropriate name and 
resource space, the association (or binding) to the application of a media transport 
protocol, the binding of the transport application to resources, creating a network 
service, and finally, the binding of the service management system to the network 
service, thereby creating a managed service. 

As an example, consider a simple teleconferencing service which provides point-to- 
point video and audio connectivity services. When a request for a conference session 
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is received, a capability check must be performed at source and destination end-points 
to ensure that the appropriate multimedia devices exist and can support the requested 
media format. Next the appropriate end-to-end network resources are reserved so that 
a connection is established between source and destination nodes. This involves 
mapping the end points which may be specified in some logical names into physical 
nodes in the network as well as determining the route that a connection must take. 
Finally, transport selection and binding is performed so that both end-devices are 
associated with the correct network terminations. 

Although the above model is realizable for simple services, the complexity of state 
management grows exponentially with the number of sub-services employed. As a 
result, complex services require additional support for state aggregation. This is 
covered in the next section. 

5.3. Managing Complex Services 

Our approach for making a service manageable introduces a new type of controller in 
the service control system: a dynamic object that is created for each new session. This 
object, which represents a service session (or service instance), makes itself accessible 
to the management system by registering with a management object, the service 
aggregator. 

For each type of service there is a service factory which handles the requests for new 
service sessions and coordinates the service creation/instantiation process. For 
example, a service factory for unicast VCs receives requests for a new VC and contacts 
the necessary VC connection managers and routers in order to set up the new VC. The 
service factory object abstracts the specific scheme used for the service creation 
process. 

The service instance represents the status and capabilities of an existing service 
session. Every service instance exports two types of interfaces. One is accessed by the 
service user and represents the control capabilities (status, modify, terminate) a user 
has once the service session is created; the other is accessed by the management system 
and represents the management capabilities. 

The service aggregator has two purposes. First, it provides a single point of access for 
the service manager to monitor and control the existing service sessions of a particular 
service type. Second, it provides aggregated or abstracted views of the service 
instances and allows the manager to manipulate sets of service instances. 

An important aspect of our model is that the designer of a service has several degrees 
of freedom when developing service management functionality. The choices include 
the selection of the state information and functionality of the service instances, the 
amount of information kept in the service aggregators and the consistency 
requirements for the management data in the aggregators. All these factors influence 
the cost of managing the service in terms of design complexity during the 
development phase and in terms of processing and computational resources needed 
during the operational phase. 
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6. QUALITY OF SERVICE, PERFORMANCE AND SCALING ISSUES 

In the previous section we dealt with the art of service creation. We will focus now on 
issues related to quality of service, performance and scaling. 

6.1. Ceil Level QOS 

In order to control the QOS at each contention point in the network a QOS abstraction 
on the object level is needed. Mapping of the states of the hardware into the software 
domain can be achieved with the QOS-extension of GSMP (a protocol proposed by 
Ipsilon Networks [22] and now an Internet RFC) that we proposed and refer to as 
qGSMP [2]. The extension provides a number of key features, including means to 
specify QOS constraints, select scheduling and buffer management policies, and 
transfer of schedulable regions [15], [16]. 

Apart from semantic changes to two fields associated with the connection management 
messages, qGSMP does not alter the original GSMP messages. Moreover, the changes 
to these two fields are such that qGSMP is backward compatible with GSMP version 
1 . 0 . 

The extensions provided by qGSMP focus on controlling the output multiplexers and 
retrieving schedulable region estimates. They provide means for selecting scheduling, 
buffer management and schedulable region estimation algorithms, setting traffic 
parameters and QOS constraints, and collecting QOS-related measurements. The 
general architecture of a switching environment using qGSMP is available on the web 
(http://comet.ctr.columbia.edu/specs/specs.html). 

The design of qGSMP follows the spirit of GSMP in the sense that it provides standard 
interfaces for development of switch-control software. By providing generic 
descriptions for expressing QOS-semantics, the controllability and programmability of 
the switch control software is significantly enhanced, allowing possibly much better 
resource utilization. 

Our implementation of qGSMP is supported by Advanced Telecommunications 
Modules Limited (ATML) switching technology. We are currently also negotiating the 
implementation on switches built by AVIDIA Systems. We also hope to be able to 
install the qGSMP interface on the switches provided by Washington University under 
NSF support. Finding efficient real-time algorithms for estimating the schedulable 
region as well as integrating the complete qGSMP interface into the xbind broadband 
kernel represents a key research priority. Having access to the schedulable region will 
create an extraordinary opportunity for experimentation with resource partitioning 
algorithms that guarantee (JOS. We have devised such algorithms based on game 
theoretic models in the past and believe that these can be readily implemented on our 
operational network. 

6.2. Performance of the Service Delivery System 

The service creation methodology described in section 5 focussed on the efficient 
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realization of services in terms of the number of states and the flexibility in accessing 
them. The design trade-offs that our architectural model is enabling pertains to the 
location and the degree of cooperation among various entities that the service creation 
process is based upon. Service creation can be executed at the periphery of the 
network, as in the case of the Internet, or in the network itself, as is the case in the 
Telephone and ATM Networks. In the framework of our architecture there is complete 
freedom in locating the objects participating in the creation process. In addition, there 
might be multiple providers offering services at various level of abstraction and 
thereby a parametrization between the ‘all or nothing’ capabilities of the Internet and 
Telephone Network is made possible. 

Modem approaches for provisioning connectivity services can be found in TINA [30]. 
In these approaches, controllers run on general purpose distributed computing 
platforms, and interact through local or remote invocations. Such approaches have the 
advantage that they allow signaling activities to be expressed in terms of high-level 
operations, instead of low level mechanisms. 

We have designed and developed a connection management architecture for an ATM 
network based on the CORBA. In this architecture, controllers are modeled as objects 
interacting through (remote or local) object invocations defined using the Interface 
Definition Language (IDL). With the objective of supporting a large number of users, 
it is essential that the connection management system exhibit high performance. In 
[1 1], the elements of an approach for realizing a high performance connection manager 
with high call throughput and low call setup delay is presented. 

An efficient design of the connection manager has to take into account that the most 
expensive operations in a distributed environment are remote object invocations. In 
particular, 

• the vast majority of the remote operations during connection setup have small 
arguments, 

• remote calls contribute the bulk of the latency in call processing, 

• most computations are executed in the communication layer. 

In order to design a high-performance connection management system, the following 
rules are followed: 

• Parallelization of the Object Call Request Execution - design the system to run 
with a maximum amount of parallelization so that processors can be kept busy as 
much as possible, 

• Caching of Network States - minimize the number of remote procedure calls 
through aggressive caching of network states (network resources cache include 
name space and bandwidth), 

• Aggregate Access to Remote Objects - aggregate access requests to remote 
objects as much as possible. 
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A first version of the connection manager described has been implemented. Running 
on a cluster of SUN Sparc 10s, initial results indicate that the system can support a 
throughput of about 100 calls/sec (or 360,000 calls/hour) with average latency of 
200ms. The intrinsic 16ms call set up time is substantially shorter then the latency data 
published by the ATM Forum [5]. 

The caching principle proposed leads to interesting performance questions. How much 
resource should be cached or, equivalently, how should resources be partitioned? 
Resources here refer to both name space, bandwidth and buffer space. There are 
essentially two main categories of algorithms that can be designed here. A competitive 
scheme among connection managers or a cooperative scheme that can be managed by 
a separate entity that is independent of the connection managers or switch controllers. 
(A competitive scheme is distributed and works with local information. A cooperative 
scheme tends to be centralized and works with global information.) 

We believe that understanding the fundamentals of allocating the resources involved, 
in particular the distributed allocation of the VCI space, will allow us the tuning of the 
key parameters resulting in a further 2 to 3 times performance improvement. This level 
of performance will bring us in the range of the current STP processors. Note that the 
other option for improving the performance of the service creation process is possible 
via the engineering of the RPC. However, this is not an option to us as we do not have 
access to the source code. 

6.3. Scaling Issues 

The implementation of the service architecture on the xbind platform will support 
experimentation with small networks. Scaling our real-time environment is 
fundamentally limited by costs, however. To experiment with the scaling properties of 
our architecture, we have realized a high-performance emulation platform, based on a 
parallel simulator. We intend to use this platform to study scaling aspects of the 
architecture and of the various telecommunication services. 

The platform we have built over the last two years allows us to closely approximate 
the functional and dynamic behavior of network control systems on the call level [12], 
[13], [14]. By providing support for real-time visualization and interactive emulation, 
it can be used to study telecommunications systems in various scenarios, such as 
different load patterns, network sizes and management operations. The current 
implementation runs on the IBM SP2 parallel processor at the Cornell Theory Center, 
which is connected to a graphics workstation in our laboratory at Columbia University 
via an ATM link. 

The emulated system and emulation support modules consist of a set of objects that 
communicate by exchanging messages, using functions provided by the simulation 
kernel. The emulated system module represents the prototype system under evaluation. 
Generally, each controller is implemented as a C++ object. Objects that interact with 
the parallel simulation kernel require minimal knowledge about the kernel— mainly 
how to send and receive messages. Therefore, the design of the emulated system 
follows the same rules as the design of controllers that run on a real network platform. 
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The major difference is in how the interaction among controllers is realized. In the 
emulated system, interaction is performed by the simulation kernel. In a broadband 
network environment, the exchange of messages is provided by a signalling system. 

The simulation kernel controls the execution of these objects and ensures that 
messages are processed in the correct order. It is realized as a parallel discrete event 
simulation (PDES) system, using a window-based synchronization protocol. In order 
to support real-time visualization and interactive control of the emulated system, the 
kernel controls the progression of the simulation time, constraining it by the 
progression of the processor time. The module for real-time visualization and 
interactive control contains a graphical interface which provides 3-D visual 
abstractions of the system state. 

Both the emulated system and the simulation kernel (also coded in C++) run on an SP2 
parallel processor located at the Cornell Theory Center (CTC) in Ithaca, New York. 
The real-time visualization and interactive control module resides on an SGI Indigo2 
workstation at Columbia University. It is written using Open Inventor, a 3D graphics 
tool kit based on Open GL, and runs as a UNIX process that communicates with the 
emulation support module via UNIX System V shared memory. The emulation 
support module is distributed on the two machines. These machines communicate 
through NYNET, an ATM network that connects several research laboratories in New 
York State. For more details as well as for download of the source code, the reader is 
directed to the URL: http://comet.ctr.columbia.edu/software. 

7. IMPLEMENTATION ISSUES 

Object-oriented methodologies and technologies are essential to us for developing 
service control and management systems. The basic elements of an object model, 
namely, concurrent objects interacting via messages, can be used to model controllers 
and their interactions in a distributed system. Such a model can be executed in a PDES 
(parallel discrete event simulation) environment (such as our emulation platform), as 
well as on a CORBA-based platform (such as xbind). 

Our requirement is that the implementation design of the service control and 
management systems can be done in such a way that their code runs on both platforms. 
Also, the GUI enabling service management functionality by an operator must run on 
both platforms. 

The servers or controllers represent perhaps the most complex implementation 
challenge in the model. The primary difficulty comes from the inherent flexibility a 
server must support - the ability to load any service script, instantiate, externalize 
transport and store its code and state and resolve all references to calls for broadband 
kernel services. The major implementation language being used is Java because of the 
easy availability of its virtual machine and class loader facility. The API stubs to the 
broadband kernel services would be implemented to make CORBA calls (or 
alternatively Java RMI calls) but would themselves be Java classes. Several Java based 
ORBs and interworking products provide this capability. Moreover, the SunSoft JDK 
1.1 release includes facilities for serializing [27] and externalizing Java object graphs. 
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These facilities will be used to implement the basic facilities component in the servers. 
It is anticipated that the B-model services will be readily implementable in Java using 
the Java beans [28] component framework. This is because these services typically do 
not have to deal with hardware or I/O which are usually lacking in Java APIs. 

Consequently, there is a wide range of possible designs for building management 
systems for a particular service, from light-weight, low-cost systems with minimal 
functionality to heavy, high-cost systems with rich functionality. More precisely, we 
believe that a trade-off analysis must be made, balancing various factors in order to 
achieve the best combination between low cost, good scalability and rich functionality 
of the management system for a specific service and a particular environment. There 
are strong reasons to engineer configurable systems which can be customized at the 
time of service deployment. Moreover, it may be necessary to allow for dynamic 
reconfiguration of a system during run-time, in response to changing needs and the 
availability of resources allocated to management tasks. 

8. CONCLUDING REMARKS 

The major theme of this paper is the realization of open programmable 
telecommunication networks. Specifically we described: 

• a new architectural foundation for the creation, deployment and management of 
future telecommunications services based on the paradigm of open programma- 
ble networking; 

• open Application Programming Interfaces (APIs) for service creation, quality of 
service control and the joint allocation of computing and communication 
resources; 

• the need to investigate scaling issues through the emulation of complex service 
scenarios arising in large scale broadband networks; 

• a methodology for evaluating the performance of the proposed service delivery 
system; and 

• recommendations for a standard set of open APIs and advanced broadband kernel 
technology to the research community pursuing open programmable networking. 

Due to space limitations, we have not discussed other key issues regarding the design 
and implementation of a service architecture for broadband networks. In particular, the 
extension of the service architecture to wireless environments, problems of security, 
problems of software reliability and more generally problems of verification and 
testing of the proposed architecture have not been mentioned at all. 

Concluding, we believe that building programmable teleconununication networks is 
one of the key research challenges that faces the networking community as we move 
towards the new millennium. To address this challenge we have initiated a number of 
new projects and international forums (OPENSIG and OPENARCH, http:// 
comet.ctr.columbia.edu/openarch) to promote the ideas which drive our research. We 
presented a number of research topics associated widi service creation, quality of 
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service, performance and scaling. Our work is backed by two software platforms 
currently in various phases of development. The xbind 1.0 platform is currently being 
used by a number of universities and industrial research laboratories worldwide. (See, 
among others, the list of participants in [25]). 
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Abstract 

Emerging communication-intensive applications require significant levels of 
networking resources for efficient operation. In the context of mobile com- 
puting environments, limited and dynamically varying available resources, 
stringent application requirements, and user mobility make it difficult to pro- 
vide sustained quality of service to applications. This paper addresses the 
above issues, and proposes a new service model in cellular mobile computing 
environments. The major results of this paper are the following: 

• An Adaptive Service model in mobile computing environments, which en- 
ables the network and applications to adaptively (re) negotiate QoS depend- 
ing on dynamic network conditions 

• An algorithmic framework that provides cost-effective resource adaptation 
in the presence of resource and network dynamics 

• A unified implementation architecture for adaptive service support 

A brief overview of an ongoing testbed implementation is provided. 



1 INTRODUCTION 

Recent years have witnessed explosive research in the development of in- 
door/outdoor mobile computing environments, which seek to provide a mo- 
bile user with not only a basic toolchest of applications - editors, compilers, 
email, ftp, telnet, etc. - but also more advanced applications such as multime- 
dia, WWW browsers, distributed file systems and databases, etc. The latter 
class of applications is communication-intensive, and will stress the wireless 
networking component of the mobile computing environments severely. A fun- 
damental problem is that the wireless medium is a scarce, shared resource 
which has very different characteristics from wireline networks, and needs 
to be managed efficiently to provide an acceptable Quality of Service (QoS) 
for communication-intensive applications. Moreover, seamless user mobility 
constitutes another QoS parameter. Therefore, the network service should be 
adaptively provided to effectively handle wireless link characteristics and user 
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mobility. We have proposed a new service model adaptive service'^ and its 
implementation on a testbed is ongoing work. This paper provides an overview 
of the adaptive service and describes our initial experiences with the testbed. 

The adaptive service has three key features: (a) a notion of QoS bounds, (b) 
mobility-related QoS parameters, and (c) an enhanced set of service classes 
that extend integrated services for wireline networks to mobile computing 
environments. 

To provide adaptive services over mobile computing environments, we have 
developed an algorithmic approach that seeks to provide (a) admission con- 
trol and resource reservations for both new and handoff flow requests, (b) 
a cost-effective and fair resource adaptation among adaptable flows, which 
also resolves resource conflicts in admission control, (c) predictive advance 
resource reservation in order to minimize handoff dropping while maintain- 
ing efficiency in resource utilization, and (d) a unified framework to support 
multiple QoS classes for a wide range of applications in mobile computing 
environments. Initial results were reported in [2, 7]. This paper explores the 
ideas of adaptive QoS in greater detail and briefly describes an ongoing testbed 
implementation. 

In order to experiment with adaptive QoS, we are building a testbed envi- 
ronment, which has the following features: (a) it treats admission control as a 
special case of the QoS adaptation, which enables an application to send data 
packets in a best effort manner before it starts resource reservation, (b) it is 
readily integrated with the standard TCP/IP protocol stack, and can even be 
used with unaware servers, (c) it advance reserves resources on next-predicted 
cell for smooth handoff, (d) it provides soft state flow management at interme- 
diate switches, which is integrated with hard state at the end-hosts, and (e) 
client-initiated resource reservation for both uplink and downlink reservations. 

The rest of the paper is organized as follows. Section 2 describes the issues 
in providing adaptive service. Section 3 defines the adaptive service model. 
Section 4 describes our algorithmic approach for supporting adaptive service. 
Section 5 presents our initial experiences on the implementation, and Section 
6 concludes the paper. 

2 ISSUES IN QOS SUPPORT FOR MOBILE COMPUTING 

The mobile computing environment we consider here has a packet-switched 
cellular architecture, consisting of a wired backbone component and a wireless 
cellular component. Base stations are connected to the backbone network and 
provide wireless networking access to portable computers within cells. Two 
cells are called neighbors if a mobile user can handoff between the cells. 

In order to provide quality of services in mobile computing environments, 
the following issues need to be addressed: 

• Wireless channel error: the case for adaptive service with QoS bounds and 

resource adaptation 
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• ‘Seamless’ inter-cellular mobility: the case for advance resource reservation 

• Maximizing network revenue: the case for cost-effective adaptation 

• Application adaptation: the case for adaptive service 



2.1 Wireless Channel Error 

The wireless channel medium has two key characteristics that invalidate the 
assumption of negligible errors: (a) bursty channel errors, and (b) location- 
dependent channel capacity and errors. Therefore, the network resources can 
no longer be assumed to remain invariant, and the effective network capac- 
ity might vary dramatically over short time scales. Therefore, the resources 
provided to applications may need to vary adaptively depending on dynamic 
network resource changes; as a consequence, our end-to-end QoS negotiation 
process results in the network providing QoS within a bounded range, i.e. 
QoS bounds. Within these bounds, the resource adaptation algorithm may 
conduct adaptation transparent to the applications and vary the QoS level 
dynamically within the specified bounds. 

2.2 User Mobility 

In a mobile computing environment, users may have a wide range of mobil- 
ity patterns, ranging from frequent handoffs between cells to almost static 
residence in a cell. Obviously, user mobility implies that the QoS negotiated 
between the application and the network in one cell may not be honored if the 
user crosses cell boundaries; besides, user mobility incurs dynamic resource 
changes for both the old cell and the new cell. For a user to be provided the 
illusion of seamless mobility, the user should not notice perceptible change 
in QoS upon mobility between cells. This motivates advance reservation of 
resources in neighboring cell(s). Moreover, the advance reservation should be 
tailored to the degree of service assurances requested by applications. 

Furthermore, users with different mobility patterns should be treated differ- 
ently. For flows from fast /frequent moving users, the major concern is “seam- 
lessness”, i.e., users care more about the invariance in the QoS level rather 
than maximizing the QoS level; for flows from slow/infrequent moving users, 
users care more about maximizing the QoS level in the current cell rather 
than seamless handoffs between cells. 

2.3 Network Revenue 

From the network perspective, the service provider needs to maximize its 
overall revenue in the long term; the goal of resource adaptation performed 
by a network is to maximize revenue over a time window by dynamically 
allocating capacity among competing flows. Since the network will incur a 
cost for each adaptation, the resource adaptation algorithm should guarantee 
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that any adaptation initiated by the network proactively (rather than as a 
result of a resource decrease) does not result in a loss of revenue, i.e., the 
adaptation is initiated only when such an adaptation will increase long term 
revenue. Thus, frequent mobility will not result in frequent adaptation. 

2.4 Application Perspective 

Many applications can adapt offered traffic to dynamic network conditions 
since they either have inherent adaptation mechanisms or can be passed 
through an adaptive filter [1]. Such applications are ideal candidate for vary- 
ing QoS with bounds. For example, most video compression standards, like 
MPEG, JPEG and JBIG, have a notion of ‘progressive mode’ or ‘hierarchical 
mode’ that can generate variable-rate video streams. 

The applications might request several service categories with different ser- 
vice commitments from wireline networks, e.g. guaranteed service^ predictive 
service, and best-effort service. Over wireless mobile computing environments, 
because the effective resource capacity is no longer invariant due to wireless 
channel errors and user mobility, the service models defined for wireline net- 
works should be modified and enhanced to effectively handle these issues. This 
motivates us to define our adaptive service model. 



3 ADAPTIVE SERVICE IN MOBILE COMPUTING 

In order to address the above issues in QoS support, we propose a new type 
of service model called Adaptive Service for mobile computing environments. 
There are several key aspects of adaptive service: (a) it provides QoS guar- 
antees/assurances within bounds (e.g. [bmin, bmax] for bandwidth); (b) it pro- 
vides mobility-related QoS parameters; (c) it defines an enhanced set of service 
classes that extend integrated services for wireline networks to mobile com- 
puting environments; and (d) it provides cost-effective resource managements. 



3.1 QoS Bound Specification 

The QoS bounds specify the QoS parameters within a range. Therefore, the re- 
source contract Rspec is characterized by < [ftmin? [dmax,dm%n\^ ^max^ h >, 
where [bmin^bmax] represents the bounds on rate, [dmaxjdmin] represents the 
bounds on maximum delay, and emax represents the maximum packet loss 
probability, h is not a numerical QoS parameter; it takes one of three val- 
ues: conservative, predictive, or best-effort, depending on the desired advance 
reservation scheme. These three values correspond to three mobility-related 
service modes to be described later: conservative reservation for location- 
independent service, predictive reservation for neighborhood-specific service 
and cell-specific service. 
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3.2 Service Classes 

(a) Guaranteed versus Predictive 

Related literature has pointed out that there are no absolute guarantees in 
a mobile computing domain, particularly due to two reasons: (a) bursts of 
wireless channel error may reduce the link capacity below the guaranteed rate, 
and (b) guarantees which are contracted in one cell may be invalid in another, 
more heavily loaded cell. Thus, all guarantees in wireless networking are con- 
ditional on currently available system capacity; On the other hand, several 
recent measurements taken for state-of-the-art indoor wireless LANs indicate 
that wireless resources are reliable over a long time scale [3]. Therefore, we 
take a middle ground: adaptive service promises assurances/guarantees on 
the QoS lower bound and provides better service beyond that in a best-effort 
manner. 

Predictive service bases its QoS assurances (reliable estimates as opposed 
to guarantees) on measured values as opposed to a priori worst-case charac- 
terization of flows [9, 4]. In most related work, measurements have typically 
pertained to the flows, while the channel capacity is typically assumed to be 
invariant. Over a wireless link, we can apply measured values to both flows 
and link capacities. Thus, there are four modes of QoS specification for a 
wireless link within our adaptive service model: 

1. Absolute Guaranteed mode: Using a priori values for channel capacity and 
a priori values for flows: e.g. guaranteed service for wireline networks, real 
time guarantees for mission-critical tasks in the wireless domain [8]. 

2. Flow- Conditioned Predictive mode: Using a priori values for channel capac- 
ity and measured values for ongoing flows: e.g. predictive service in wireline 
networks. 

3. Channel-Conditioned Guaranteed mode: Using measured values for channel 
capacity and a priori values for flows: e.g. conditional guarantees in wireless 
links. 

4. Channel/Flow-Conditioned Predictive mode: Using measured values for chan- 
nel capacity and measured values for ongoing flows: e.g. predictive service 
in wireless links. 

(b) Mobility-Related QoS Parameter 

We consider three possible service specifications to account for mobility: 

1. Location-independent service: The service specifications are valid for a flow 
independent of its location in the network. This service would require ad- 
vance reservation in all cells the user might visit (as specified via e.g. the 
mobility proflle) [5]. 

2. Neighborhood-speciflc service: The service speciflcations are valid for a flow 
in its current cell and its neighbors [7, 11]. As a user moves, advance reser- 
vations in neighbors are made and canceled dynamically. We consider two 
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flavors of advance reservation: (a) conservative reservation in all neighbors 
[11], and (b) predictive reservation in only the next-predicted cell [7]. 

3. Cell-specific service: The service speciflcations are valid only in the current 
cell. 

In our model, we deflne a special QoS parameter h to support all the above 
three service modes. However, the provision for location-independent ser- 
vices is likely to incur an enormous resource overhead; hence, we focus on 
neighborhood-speciflc and cell-speciflc services. 

3.3 Cost-Effective Adaptation 

In mobile computing environments, in order to shield flows from frequent 
adaptation due to rapid resource fluctuation (caused by time- varying effective 
wireless link capacity and user mobility), we adopt a cost-effective approach 
for rate adaptation. Essentially, the network associates an adaptation cost for 
each flow, and will not initiate new adaptation for a flow unless the revenue 
gain of a flow would be able to compensate its adaptation cost upon detection 
of a network resource change. Through this way, the network defines a dynamic 
adaptable set, and designs its adaptation policy for flows within this set so 
that it maximizes its overall revenue subject to resource and flow demand 
constraints. It turns out that the optimal adaptation policy is a max-min fair 
rate allocation among the flows in the adaptable set for many scenarios. 

4 ALGORITHMS FOR ADAPTIVE SERVICE 

In this section, we provide an overview for three key resource management 
algorithms and the interaction between them. 

4.1 Admission Control and Resource Conflicts 

Admission control converts end-to-end QoS requirements into per-hop require- 
ments and tests for the availability of resources at intermediate nodes [6]. It 
is conducted for both a newly arriving flow and a handoff&ow. For flows with 
QoS bound specification, the network is only committed to provide assurance 
for the QoS lower bound, and provides better service beyond the lower bound 
depending upon the dynamic availability of the network resources. The major 
difference of admission control policies for predictive and guaranteed services 
is whether they use measured values or a priori worst-case characterizations. 
Admission control is the same for handoff and new flows except that handoff 
flows may already have advance reserved their minimum requested resources. 

The introduction of QoS bounds introduces a new problem for admission 
control, i.e. resource conflict The problem of resource conflict arises when 
the network cannot accept a new flow without reducing currently allocated 
resources (within pre-negotiated QoS bounds). The resolution of resource con- 
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flicts readjusts the resources allocated to each flow but does not violate the 
pre-negotiated bounds of existing flows. In our framework, we provide a uni- 
fled approach for resource conflict resolution and resource adaptation. 

4.2 Predictive Advance Resource Reservation 

To provide neighbor-speciflc predictive advance reservation, our algorithm 
predicts the next cell for a mobile user and makes advance resource reservation 
based on portable/cell profiles. We distinguish static portables from mobile 
portables. A portable is labeled ‘mobile’ if it has performed a handoff within a 
specified time window, otherwise it is labeled ‘static’. A flow is labeled static if 
both its end hosts are static, otherwise it is labeled mobile. For a mobile flow, 
the minimum acceptable resources are reserved in its next-predicted cell(s) 
of its mobile end-host (s). Otherwise, bandwidth is not reserved in advance 
in its neighboring cells on a flow/portable-speciflc basis; instead, each base 
station in the neighboring cells sets aside a dynamically adjustable fraction 
of resources to accommodate “unforeseen” events (e.g. sudden mobility of 
static portables). This common reserved resource pool may also handle wrong 
predictions for mobile movements. A detailed discussion is presented in [2]. 

4.3 Resource Adaptation 

Adaptive Service provides QoS within bounds; this implies that flows can be 
accepted so long as their lower bounds can be satisfied. However, in order to 
increase the utilization of the network and provide better service to applica- 
tions, excess resources (after the satisfaction of the lower bounds of ongoing 
flows) need to be distributed effectively among the flows. 

In order to perform resource adaptation, we propose a new adaptation algo- 
rithm which (a) guarantees no loss of revenue for networks due to adaptation, 
(b) maximizes network revenue and the adaptation policy achieves max-min 
fair allocation among the adaptable flows, (c) exploits only the current in- 
formation on available resources, and does not make predictions for resource 
changes in the future, (d) shields wired backbone flows and static flows from 
frequent resource fluctuations due to mobility of other flows, (e) presents an 
efficient distributed framework which accomplishes the adaptation using only 
local information and converges fast, and (f) maintain feasibility at all times 
during the adaptation process. 

Specifically, when a network link performs adaptation, it first determines 
its current adaptable set, which consists of flows that will adapt at this time. 
A flow is considered adaptable only if its revenue gain via adaptation has paid 
off its adaptation cost. For flows within the adaptable set, a network link 
attempts to maximize its total revenue over all adaptable flows sharing it. 
It can be shown that the optimal solution allocates the excess resources in 
a max-min fair sense among contending flows within the adaptable set. Our 
implementation of the cost-effective adaptation algorithm imposes a ‘con- 
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trol tree’ structure on the graph, for propagating the state information and 
computing max-min bandwidth allocation. As a result, the implementation 
propagates information through the control tree in an effective manner and 
achieves max-min adaptation with few steps and propagating limited state, 
while maintaining feasibility all the times during adaptation. Details of the 
adaptation algorithm are beyond the scope of this paper. Readers may refer 
to [2] for a preliminary description. 



4.4 Interaction among Resource Management Algorithms 

Provision of adaptive services in mobile computing environments has involved 
the following algorithms to interact: (1) service specification, (2) routing, (3) 
resource reservation, (4) admission control, (5) scheduling, (6) resource adap- 
tation and resource conflict resolution, and (7) advance reservation based on 
mobility prediction. The interactions among them are illustrated below via 
steps involved in flow establishment or handoff. 

When a new unicast flow request is made, the following actions occur: 

(1) The initiating host specifies the QoS bounds and the service mode. 

(2) The routing algorithm computes a route for this flow. 

(3) The two end hosts are subjected to the static/mobile test. 

(4) The resource reservation algorithm is invoked along the route for the 
new flow. At each intermediate switch, a local admission test is performed 
in the forward phase. All admission tests for both static and mobile flows 
are performed only with respect to the lower bound of requested resources. 

(5) An admission test may return one of three results: flow accept^ conflict 
detection, and flow reject If the admission test at each intermediate switch 
in the forward pass is either flow accept or conflict detected, then in the 
reverse pass, the new flow is admitted, and a conflict resolution algorithm 
is performed (if required). 

(6) Resource reservation for a newly admitted flow may end up performing 
two tasks: (a) conflict resolution, and (b) excess resource allocation. Both 
invoke the cost-effective adaptation. 

(7) For a mobile flow, the next cell of the mobile end-host is predicted, 
and the lower bounds of flow resources are reserved in this next cell. The 
predictive advance reservation is only applied when h = predicted in the 
Rspec; when h = conservative, a brute force advance reservation algorithm 
is performed over all neighboring cells; when h = best-effort, no advance 
reservation is performed. 

(8) For mobile flows that turn static and join the adaptable set, resource 
adaptation is performed (i.e. Step 6) after the change is detected. 



For the case of flow handoff, the steps are similar. 
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Figure 1 Four components and their interaction 



5 IMPLEMENTATION 

In order to experiment with adaptive service, we are building a testbed im- 
plementation of a mobile computing environment. The testbed consists of 
Gateway P6-200s (network ‘software’ switches and base stations) and TI 
Travelmate P-120s (mobile hosts), all of which run Linux 2.0.30. The wired 
backbone is a point to point switched Ethernet with P6-200s functioning 
as switches. The wireless network is WaveLAN. The Ethernet device driver 
‘de4x5.c’ and WaveLAN device driver ‘wavelan_cs.c’ were modified to im- 
plement WRR(Weighted Round Robin) scheduling, admission control, and 
resource reservation at intermediate switches. 

There are four main components in our resource adaptation implementa- 
tion; application programs (client /server), resource adaptation server, runtime 
library, and intermediate switches. Figure 1 represents the interaction between 
them. Currently only two QoS parameters have been implemented: data rate 
and delay. Error and handoff QoS parameters are on-going work. 

The main features of our implementation are as follows: 

• Data transmission and resource reservation are decoupled. Hence it is read- 
ily integrated with the standard TCP/IP protocol stack; In fact it is pos- 
sible to support QoS even with ‘unaware’ applications. In our implementa- 
tion, admission control is treated as a special case of QoS adaptation; Thus 
an application can send data packets before resource reservation in a best 
effort manner. Only when the application wants QoS guarantees, does it 
start resource reservation. 

• It uses soft state extensively in intermediate switches for resource reser- 
vation, advanced reservation, flow management, and mobility support. At 
the end host, applications explicitly register, deregister, and make QoS re- 
quest with the adaptation server. Using soft state, the network switches 
periodically free resources unless explicit refresh messages are exchanged. 
This enables us to handle mobility easily, since resources on defunct routes 
are automatically freed upon a timeout. 

• The resource reservation is initiated by an application client for both the 
uplink and the downlink. The reservation process finishes in 2-way hand- 
shake whether the resource reservation is successful or not. 




34 



Part One Mobile Communication 



5.1 Adaptation Server 

The resource adaptation server is a simple stateless server, which manages 
end-to-end QoS. Typically it resides at the ‘aware’ end hosts and base stations. 

The main functionality of the resource adaptation server is to perform end- 
to-end QoS adaptation and resource reservation on behalf of the application. 

QoS parameters, delay and rate are associated with flows. A flow is iden- 
tifled by the following parameters: <src addr, src port, dest addr, dest port, 
protocol>, which constitute the flow id. 

Applications register /deregister flows with the adaptation server. When the 
server receives a QoS request from an application, it sends a QoS adaptation 
request message to the peer server of the flow. As the message traverses in- 
termediate hops, each switch performs reservations for uplink and downlink 
flows on the downstream and upstream interfaces respectively. For a mobile 
flow, the adaptation server may communicate with the neighboring base sta- 
tions in order to initiate advance resource reservation. Section 5.3 describes 
an example. 

A runtime library (register , deregister , send-QoS-request , retrievejQoS) 
is provided to applications as an interface to the adaptation server. 

5.2 Network Switches 

Each network switch implements a hierarchical Weighted Round Robin (WRR) 
scheduling algorithm. In addition, the modified Ethernet and WaveLAN de- 
vice drivers perform admission control and resource reservation upon a QoS 
request. The modified device drivers have a hierarchy of three queues: (a) 
FIFO queue for control packets, (b) WRR queue for reserved flows, and (c) 
Round Robin queue for best effort traffic. 

If an adaptation request on the uplink/downlink can be satisfied by the 
switch, it reserves the resources on device drivers at the uplink/downlink for 
the flow. Otherwise it sets the flag in the control message to inform the failure 
to other switches and the adaptation servers. 

Resource reservation in intermediate switches involves a basic 2- way hand- 
shake. The client initiates resource reservation request for both the uplink 
and the downlink. On the forward pass, bandwidth admission control/resource 
reservations are performed. On the reverse pass delay admission control/resource 
reservations are made. If either admission control fails, then no refresh packets 
will be sent by the adaptation server at the client and reserved resources will 
be freed eventually. Note that since messages are exchanged between adapta- 
tion servers, the application server can be ‘unaware’ of QoS. 

5.3 Typical Resource Adaptation Steps 

Figure 2 shows typical resource adaptation steps. For simplicity, only one 
network switch is shown in the figure. 
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Figure 2 Typical interaction between resource adaptation servers 

1. An application client opens a flow and sends/receives data packets in a 
best effort manner. 

2. When the application wants to associate QoS with the flow, it registers the 
flow to the local adaptation server. 

3. Then it sends a QoS_Request message to the adaptation server. 

4. The local adaptation server sends a QoS-Request to the remote adaptation 
server. During this request pass, bandwidth adaptation for both the uplink 
and the downlink is done at the intermediate switches. 

5. The remote adaptation server updates its QoS entry table then signals the 
application server. An unaware application server may ignore the signal. 

6. The remote adaptation server sends a Response message back to the local 
adaptation server. During this response pass, delay adaptation is performed 
for both the uplink and the downlink. Note that if the bandwidth adapta- 
tion were unsuccessful, then delay adaptation will not be performed. Also 
note that if delay adaptation were unsuccessful, the reserved resources at 
intermediate switches will be freed after timeout. 

7. At any time, an application client/server can query current the QoS for a 
flow by invoking the RetrieveQoS function to contact its local adaptation 
server. 

8. Since resource reservation at intermediate switches use soft state, the adap- 
tation server sends KeepAlive packets periodically to refresh the flow re- 
sources. 

9. For advance reservation, the base station of the next-predicted cell is no- 
tified to initiate a QoSjrequest. This request terminates at the nearest 
branch point, and is identified as a secondary flow. 

10. Upon handoff, the adaptation server in the previous cell ceases to send a 
KeepAlive message. Consequently resources along this path are released 
after timeout. 

6 CONCLUSION 

Four factors motivate the work in this paper: (a) user mobility and wire- 
less channel error motivate the definition of adaptive service model, (b) the 
resource dynamics introduced by wireless links and user mobility motivates 
resource adaptation, (c) a cost-effective resource management motivates our 
algorithmic framework for resource adaptation, (d) the enhanced set of mul- 
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tiple QoS classes motivates our unified implementation structure to provide 
adaptive services. 

This paper has proposed a new service model “adaptive service” for mo- 
bile computing environments, and describes an ongoing implementation for 
providing adaptive service. The ultimate goal is to build an integrated ser- 
vices cellular network that provides quality of services for a wide range of 
applications. 
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Abstract 

There has recently been considerable interest in quality of service management 
architectures for high speed networks. In contrast, however, there has been less 
research on appropriate architectures for mobile computing. This paper addresses 
the issue of quality of service in a mobile environment. In particular, we describe a 
distributed systems platform. Limbo, which is intended to support the development 
of demanding, mobile-aware distributed applications in a heterogeneous networking 
environment. This platform is based on the concept of tuple spaces and is extended 
with support for quality of service management. The emphasis of quality of service 
management is on monitoring and adaptation, although support is dso provided for 
other functions such as admission control and resource reservation. The paper 
argues that there are significant benefits from using a tuple space paradigm in such 
an environment, particularly in terms of the ability to adapt to changes in network 
connectivity or the more general environment. 
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1 INTRODUCTION 

There has recently been considerable interest in the development of architectures for 
quality of service (QoS) management (Hutchison, 1994). Such architectures are 
generally motivated by the requirement to support multimedia applications in a 
networked environment and enable the user to specify their nonfunctional 
requirements in the form of a QoS contract. The QoS management architecture 
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then provides a range of functions to achieve and sustain the QoS requirements as 
specified in this contract. Examples of such functions include negotiation, 
admission control, resource reservation, monitoring and renegotiation. By 
selectively applying such functions, it is possible to provide varying levels of QoS 
guarantee (such as best effort, predictive or deterministic). 

Existing QoS architectures, however, generally make implicit assumptions 
about the underlying network. In particular, they assume that the network offers a 
relatively stable environment in terms of connectivity, available throughput, delay 
and delay jitter. They ensure sufficient resources are available through admission 
control and resource reservation and compensate for small changes in the 
underlying network service through software feedback mechanisms. However, such 
approaches are not appropriate in a mobile environment, where the end system may 
roam from network to network experiencing dramatic changes in throughput and 
connectivity. In such systems, the emphasis for QoS management must change 
from providing levels of guarantees to supporting monitoring and adaptation. 

This paper considers the role of quality of service management in a mobile 
environment. We are particularly interested in QoS management to support 
demanding distributed applications (requiring multiparty multimedia 
communications). We propose a novel approach based on tuple spaces, exploiting 
the properties of time and space decoupling exhibited by such systems. We 
demonstrate how tuple spaces can be enhanced to support QoS management 
functions within an overall QoS architecture. 



2 QOS AND MOBILITY 
2.1 Heterogeneous Networks 

Early research in mobile computing focused on mechanisms to enable access to 
services across wireless networks such as GSM. Current research, however, is 
investigating techniques to access services over a heterogeneous networking 
infrastructure where the precise network will vary over time (Katz, 1994). Given 
such a heterogeneous infrastructure, the most dominant characteristic of mobile 
computing is change. For example, end systems can experience dramatic changes 
in the available bandwidth and bit error rates, or discover new functionalities are 
available in the underlying network. At the most extreme, end systems can move 
from periods of high to partial connectivity, through to complete disconnection. 

The approach in existing QoS architectures is, where possible, to mask out 
change and hence present a stable service to the application (effectively providing a 
level of network transparency). This is achieved through combining QoS functions 
such as admission control, resource reservation and maintenance. In our view, such 
an approach is not sustainable in a mobile environment. In such an environment, 
the emphasis should not be on transparency but on making information available 
to applications and empowering applications to make the necessary changes. Such 
an approach relies on the provision of QoS management functions supporting 
monitoring and adaptation. To complement this, the underlying system must be 
amenable to adaptation, including the ability to adapt to periods of disconnection. 
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This is not to say that existing approaches to QoS management are invalidated. 
Rather, strategies such as admission control and resource reservation can be used 
for component networks and can provide guarantees while the end system remains 
connected to that particular network. The architecture must, however, accommodate 
changes in underlying network service through the additional mechanisms we seek. 



2.2 Other Factors 

Mobile hosts must also deal with other changes in their environment. One 
important environmental factor is that of power availability and consumption. 
Despite significant developments in areas such as low-power processors, the 
availability of power remains an important concern for mobile users. By providing 
access to power information, applications may utilise hardware power saving 
functionality as appropriate. 

Another important environmental factor is the current physical location of the 
end system. Such information can be exploited in numerous ways. For example, 
such information can be used for the proximate selection of services (Neuman, 
1993) whereby services are selected on criteria such as physical distance from the 
mobile host and current cost of access. Schilit has also proposed the more general 
concept of context-aware applications (Schilit, 1994). One example put forward is 
that of a memory jogger which allows users to specify that a certain message 
should be displayed when a series of location and temporal based conditions are 
met, e.g. 'remind me to do task t next time I meet users x and y'. 

In essence, we are proposing to broaden the scope of QoS monitoring and 
adaptation to include general environmental characteristics such as power 
availability, rate of consumption of power, physical location and time. In this 
way, applications can adapt to changes in the underlying environment. However, 
this introduces a problem. Existing systems provide access to QoS functions 
through abstractions over communications. For example, more recent distributed 
systems platforms support the concept of bindings as abstractions over 
communications services. Crucially, bindings generally offer interfaces for QoS 
management functions such as monitoring and adaptation. This implies, however, 
that there would be one means of accessing and disseminating information about 
the network and another means of dealing with other environmental characteristics. 

The close liaison between communications and QoS implies that 
communications must be established before QoS information can be obtained. This 
approach prohibits the system from making speculative decisions. For instance, 
the system cannot check the QoS between itself and some remote system to 
determine whether it wishes to contact that system without first establishing the 
binding to obtain a handle for gathering the QoS information. We therefore seek a 
uniform approach to QoS management which accommodates both communications 
and more general environmental considerations. Furthermore, such an approach 
need not be dependent on the existence of actual bindings between hosts. 
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2.3 Overall Analysis 

In our opinion, the most crucial role of QoS management in mobile environments 
is to facilitate adaptation. To support this, the underlying distributed systems 
platforms must collate and manage QoS Information for presentation to higher 
layers, enabling feedback and control throughout the architecture. In addition, we 
believe the close association of QoS with communications present in existing 
approaches to be less than ideal. The remainder of this paper describes a new 
distributed systems platform. Limbo, based on the tuple space paradigm which can 
provide a uniform mechanism for integrating QoS into applications. Firstly, 
however, it is necessary to provide some background information on tuple spaces 
and the rationale for tuple spaces in distributed mobile environments. 



3 BACKGROUND ON TUPLE SPACES 

3.1 What are Tuple Spaces? 

Tuples comprise of collections of typed data fields. Each field is either an actual, if 
it contains a value, or a formal, if it does not. Collections of (possibly identical) 
tuples exist in shared data objects called tuple spaces. Tuples can be dynamically 
deposited in and removed from a tuple space, but not be altered while resident in it. 
However, changes can be made to a tuple by withdrawing it from the tuple space, 
amending and then reinserting it (Gelernter, 1985b). Tuple spaces are shared 
between collections of processes, all of which have equal access to its contents. 

The tuple space paradigm was conceived by researchers at Yale (Gelernter, 1985a) 
and was embodied in a coordination language called Linda. Linda is not a 
standalone computational language, instead Linda operators are embedded in host 
computational languages (e.g. C or Java). The model defines four basic operators: 

• out inserts a tuple, composed of an arbitrary mix of actual and formal fields, 
into a tuple space. 

• in extracts a tuple from a tuple space, using its argument as a template, or 
anti-tuple, against which to match. Actuals match tuple fields if they are of 
equal type and value; formals match if their field types are equal. If all 
corresponding fields match the tuple is withdrawn and any actuals assigned to 
formals in the template. Tuples are matched nondeterministically and in 
blocks until a suitable tuple can be found. 

• rd is a version of in which does not withdraw matches from the tuple space. 

• evai is similar to out but creates active rather than passive tuples, spawning 
separate processes to evaluate each field. Such active tuples subsequently 
evolves into ordinary, passive tuple resident in the tuple space. 

3.2 Why Tuple Spaces? 

The tuple space paradigm has two very important properties: 
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• Time decoupling: In tuple spaces, tuples are persistent and the sender and 
receiver do not have to exist at the same time (Bjomson, 1991). A sender may 
place a tuple into tuple space and then terminate execution. At some point in 
the future, a receiver can invoke the in or rd primitives and obtain this tuple. 
It is quite possible that the receiver did not exist when the tuple was created. 

• Space decoupling: The sender does not need to be aware of the identity of the 
receiver (or multiple receivers if rd operations are used). The sender simply 
places the tuple in tuple space and expects one or more processes to access the 
tuple at some point in the future. Their identity is unknown (i.e. 
communication is anonymous). It is, however, also possible to produce tuples 
for an identified consumer process, termed directed communication ^ by 
encapsulating destination information in tuples. Several such schemes have 
been proposed, including an approach based on Amoeba ports (Pinakis, 1992). 

It is recognised that these properties support the construction of flexible and 
fault-tolerant parallel applications. We contend that the same properties can support 
the construction of distributed applications in a mobile environment. The majority 
of existing distributed system platforms are based on the remote procedure call 
(RPC) paradigm. In this style of interaction, clients locate an appropriate service 
through, for example, a trading service. They then bind to this service and invoke 
operations on it over a period of time. This makes the assumption that the sender 
and receiver exist at the same point in time and synchronise in order to exchange 
data (with the precise degree of synchronisation varying from service to service). 
Consequently, such systems have problems during toth long and short periods of 
disconnection. A number of platforms overcome this deficiency by introducing an 
element of buffering. In this way, the platforms attempt to maintain RPC 
semantics in the face of variations in network connectivity. Tuple spaces, however, 
overcome this problem by decoupling senders and receivers in time. 

Space decoupling also offers benefits for mobile computing. The advantage of 
space decoupling is that there is no binding between a client and a server. Rather, a 
number of processes can service a particular request (as specified in a tuple). This 
increases fault-tolerance as the architecture naturally deals with failure of particular 
nodes. In a mobile environment, this property can be exploited to deal with the 
unavailability of particular services. For example, an end user can request a print 
service by inserting an appropriate tuple in tuple space. Any print service can 
respond to this request. As print services become unavailable, other services can 
take over. In this example, it would also be possible to exploit location 
information (if available) to dynamically select the nearest service. 

The combination of space and time decoupling implies that there is no direct 
concept of a connection in tuple spaces. Consequently, QoS requirements must be 
associated with the overall tuple space or with individual tuples. The result of this 
is that the system has more flexibility to reconfigure itself to attain the desired 
level of QoS. We return to this aspect in section 4.2.3 below. 

Finally, tuple spaces provide a very natural means of disseminating information 
to a variety of potential recipients. The paradigm directly supports multiparty 
communications and encourages the ready availability of global information. We 
exploit this later property to make QoS management information available to any 
interested parties. This aspect is discussed in more detail in section 4.2.2. 
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4 A DISTRIBUTED SYSTEMS PLATFORM BASED ON TUPLE 
SPACES 

4.1 General Approach 

We have designed a new distributed system platform, called Limbo, to support 
demanding distributed applications in a mobile environment. This platform is 
based on the concept of tuple spaces, augmented by mobile agents. Mobile agents 
reside above tuple spaces and interact with the tuple space, carrying out a particular 
computation. They can be written in any language supporting the creation of 
mobile code (e.g. Java or TCL) as long as the language provides a conformant 
interface to tuples spaces (thus supporting the requirement for interoperability and 
portability required by modem middleware platforms). Note that agent mobility is 
naturally supported by the tuple space model; agents simply stop interacting with 
the tuple space, relocate and then restart their interaction. As an enhancement, 
agents are also generally stateless', all state is assumed to be in the tuple space. As 
tuples are persistent and globally available, replicating agents is trivial. In other 
words, there is no need for a consistency algorithm; this is directly provided by 
tuple spaces. Agents are classified as system agents, already provided in the 
environment, and application agents, introduced into the environment by the 
programmer. This distinction is, however, not particularly rigid. The application 
programmer is free to introduce additional system agents into the environment. 

We support the following key extensions to this basic architecture: i) multiple 
tuple spaces which may be specialised to meet application level requirements, e.g. 
consistency, security or performance, ii) an explicit tuple type hierarchy supporting 
dynamic subtyping, and iii) a QoS management architecture supporting monitoring 
and adaptation. We look at the first two extensions in this section and the QoS 
management architecture in section 4.2. 

The original tuple space model was designed to support parallel programming on 
shared-memory multi-processor systems and features a single, global tuple space. 
More recent models have proposed the introduction of multiple tuple spaces to 
address issues of performance, partitioning and scalability (Hupfer, 1990). This is 
important for performance in a distributed environment and critical in an 
environment where communications links are costly and unreliable. 

We provide a class of system agent which can create new tuple spaces for 
applications. These tuple spaces are configurable to meet application specific 
requirements (Hupfer, 1990). For example, in addition to general purpose tuple 
spaces we allow the creation of tuple spaces with support for security (user 
authentication), persistence and tuple logging (for accountability in safety critical 
systems). Crucially, it is also possible to create a range of QoS-aware tuple spaces. 

In order to create a new tuple space clients communicate with the appropriate 
system agents via a universal tuple space. Clients specify the characteristics of the 
desired tuple space and place a create_tupie_space request into the common 
tuple space. The appropriate system agent accesses this tuple, creates a tuple space 
with the required characteristics and places a tuple of type tupie_space in the 
common tuple space. The fields in this tuple denote the actual characteristics of the 
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new tuple space (which may be different to those requested in best-effort systems) 
and a handle through which clients can access the new space. 

Agents can select between tuple spaces by means of a use primitive. This 
primitive communicates with a membership agent through the universal tuple 
space, returning a handle if the tuple space exists and certain other criteria are met. 
The precise criteria vary from tuple space to tuple space and can include checks on 
authentication and access control functions or relevant QoS management functions. 
We return to this latter aspect in section 4.2 below. Handles can later be discarded 
by an agent using a discard primitive. This places an appropriate tuple in the 
universal tuple space so that the membership agent can take appropriate steps. A 
tuple space can be destroyed by placing a tuple of type terminate in it. Such 
tuples are picked up by system agents within the tuple space which invoke a 
system function to gracefully shut down the tuple space. 

Note that this model can be applied recursively. It is possible to access a tuple 
space through the universal tuple space and find this tuple space has system agents 
supporting the creation of and subsequent access to further tuple spaces. This 
recursive structure provides a means of creating private worlds with fine grain 
access control. 

In our model, we allow an optional type to be associated with each tuple. Typed 
tuples can be organised to form a hierarchy by establishing subtyping relationships 
between them. The benefits of subtyping in a distributed environment have been 
comprehensively investigated within the ODP community as part of their work on 
interface trading (ISO/ITU-T, 1997). In this model subtyping enables added 
flexibility when matching service offers to client requests. 

4.2 QoS Support 

4.2.7. Overview 

As mentioned above, the Limbo architecture supports the creation of multiple 
tuple spaces through a number of system agents. In order to support quality of 
service, we provide a range of system agents to create QoS-aware tuple spaces, A 
QoS-aware tuple space is one that supports a number of QoS management 
functions (the precise details vary from system agent to system agent). This 
architecture is completely extensible; the programmer is free to define new system 
agents enabling the creation of different styles of QoS-aware tuple spaces. 

QoS-aware tuple spaces will typically have a more sophisticated membership 
agent which will perform certain QoS-management functions in order to provide 
guaranteed or predictive classes of service. In particular, the membership agent will 
cooperate with admission control and resource reservation agents in order to provide 
the required class of service. The membership agent will only issue a handle if the 
admission control test is passed and resources requested available. The two system 
agents can implement any of the available algorithms for admission control and 
resource reservation. In addition, the architecture is completely open. Different 
tuple spaces can have different admission control and resource reservation agents. 
The programmer is also free to extend the available services, hence offering a new 
class of tuple space. Note that these agents are not compulsory for QoS-aware 
tuple spaces; if not present, the tuple space will offer best-effort service. In general. 
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this architecture allows a wide range of tuple spaces to be created offering best- 
effort, predictive or guaranteed classes of service for a variety of different traffic 
types (e.g. constant bit rate, variable bit rate, periodic or bursty traffic). 

In QoS-aware tuple spaces, individual tuples can also have designated QoS 
attributes specifying the expiration time and the priority of the tuple. In the case of 
a tuple which is the subject of an out operation, the expiration time refers to the 
time the tuple is allowed to reside in the tuple space before being deleted. In the 
case of a tuple template used as an argument to in or rd operations, the expiration 
time refers to the time for which the request can block before timing out. The 
priority attribute is used by the tuple space implementation in both the end system 
and network to reorder traffic upon congestion. (Note that we are also currently 
debating whether to replace the priority field with a deadline or indeed with a 
combination of both values as proposed, for example, in (Nieh, 1995)). 

The approach described above is designed to resolve the conflict between the need 
for QoS-guarantees on services and the problems that can occur in a mobile 
environment. With appropriate admission control and resource reservation 
functions, a tuple space can guarantee to make tuples available to agents using that 
tuple space with certain QoS guarantees if and only if significant changes do not 
occur in the underlying communications infrastructure. Thus, although the 
approach is asynchronous and connectionless in nature, tuple spaces can be used to 
provide real-time guarantees on, say, a video stream (again, provided the available 
network QoS remains relatively stable). In a mobile environment this cannot, 
however, be guaranteed as nodes will roam between networks experiencing dramatic 
changes in the available bandwidth. In such cases, it is both undesirable and 
impossible to continue with the desired quality of service level. The advantage of 
tuple spaces (coupled with mobile agents) is that, in such circumstances, they 
naturally support reconfiguration. The persistent nature of tuple spaces also helps 
to overcome periods of disconnection. However, to fully exploit this potential, 
support must be provided for QoS monitoring and adaptation, as described below. 

422, Support for Monitoring 

Every Limbo site has an associated management tuple space together with a 
number of QoS monitoring agents. These agents monitor key aspects of the 
system and inject tuples representing the current state of that part of the system 
into the management tuple space. The precise configuration of QoS monitoring 
agents can vary from site to site. As above, the architecture is open and new QoS 
monitoring agents can readily be added to the configuration. Monitors can observe 
events at various points in the system including the: rate of injection of tuples into 
a given tuple space, rate of access to tuples in tuple space (through in or rd 
operations), total throughput currently achieved from that node, the cost of the 
current channel, level of connectivity, power availability, rate of consumption, 
processor load and current physical location of that node. In this way, the 
architecture deals uniformly with a range of QoS parameters relating to both 
communications and the general environment. In addition, the architecture can 
provide information relating to a particular tuple space or to the node in general. 

This architecture has the advantage that information pertaining to a node may be 
globally accessible. By placing this information in tuple space, other sites can 
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access this information through that tuple space. This means agents on different 
nodes can find out about the location of a particular site, its current processor load, 
the throughput it is experiencing, etc. A site can, instead, keep this information 
private by selecting a membership agent which prevents access from other sites. 

4.2.3, Support for Adaptation 

The Limbo architecture supports a variety of mechanisms for adaptation. Such 
mechanisms are typically employed on detecting a significant change as a result of 
QoS monitoring. One of the main techniques for achieving adaptation is that of 
filtering agents. Filtering agents are a special form of bridging agent. A bridging 
agent links arbitrary tuple spaces together and controls the propagation of tuples 
between them. In its simplest form, a bridging agent is a process which performs 
repeated rd operations on one tuple space and out's corresponding tuples into a 
second tuple space. Filtering agents are then bridging agents which perform 
transformations on tuples to map between different levels of QoS. They rely on 
typing information to identify the subset of tuples to be filtered. 

Filtering agents could be used to translate between different media formats. More 
commonly they are used to reduce the overall bandwidth requirements from the 
source to target tuple spaces. For example, a filtering agent could act between two 
tuple spaces dealing with MPEG video and only propagate I-frames to the target 
tuple space. The filtering agent could also perform more aggressive bandwidth 
reduction, for example by performing colour reduction on I-frames. The importance 
of filtering agents is that they allow parallel tuple spaces to offer the same service, 
e.g. the propagation of video frames, at radically different levels of QoS. An agent 
can therefore select between the different levels depending on their level of 
connectivity. On detecting a drop (or an increase) in available bandwidth, they can 
switch to another tuple space. 

The architecture also supports several other forms of adaptation. For example, on 
detecting QoS violations, a sending agent can choose to adapt the rate at which 
tuples are injected into tuple space. This is, however, a rather crude mechanism in 
an environment supporting multiple receivers with potentially different levels of 
connectivity. More interestingly, a receiver can selectively in or rd certain types 
of tuple and ignore others on detecting a drop in their connectivity. For example, 
they can select I-frames only and ignore P- and B-frames (achieving a similar effect 
as above). Similarly, they can select base encodings in hierarchical encoding 
schemes. With the appropriate allocation of priorities on these tuple types, it is 
also likely that the underlying implementation will be able to discard the lower 
priority tuples on detecting congestion, implying that they need not be transmitted 
over a lower bandwidth link. 

Finally, mobile agents provide considerable scope for adaptation. For example, it 
is possible to migrate an agent to a different site. Similarly, it is possible to create 
a new agent to act as your proxy on a well-connected site. Finally, with replicated 
agents, it is possible to access a replica that is either cheaper to access or is at a 
location with better levels of connectivity. 
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5 IMPLEMENTATION DETAILS 

The platform has a decentralised architecture and is designed to be scalable: the state 
of each tuple space is decentralised across participant sites. Essentially, each site 
accessing a given tuple space maintains a local cache containing a (partial) view of 
that tuple space. The architecture uses a multicast protocol to manage consistency 
of the different views. Crucially, this uses the Scalable Reliable Multicast (SRM) 
protocol which operates as a lightweight service on top of IP multicast and offers a 
highly scalable means of achieving reliable group communications within the 
Internet (Floyd, 1995). The protocol has previously been used to implement a 
variety of services including a collaborative whiteboard tool, wb (Floyd, 1995) and 
a distributed file system, Jetfile (Gronvall, 1996). 

The protocol operates as follows. Every tuple space is allocated an IP multicast 
group address. SRM then uses IP multicast to deliver messages to all interested 
parties (i.e. the sites currently using that tuple space). IP multicast is, however, 
unreliable and hence it is necessary to deal with lost messages. The most obvious 
approach would be to have acknowledgements from every receiver in the group, but 
this would suffer from acknowledgement explosion and hence compromise 
scalability. To overcome this problem, SRM does not acknowledge receipt of 
messages. Instead, on detecting missing messages, the protocol issues a repair 
request to the group. Any member of the group can respond to this request and 
sites wait for a random period based on their perceived distance from the requester 
before responding. They also snoop to see if anybody else has responded in the 
meantime. With this approach, it is likely that the closest site will respond to the 
repair request by retransmitting the lost data. 

The SRM protocol adopts an application level framing philosophy, leaving key 
policy decisions to the application. In particular, applications must detect missing 
messages and request repairs as necessary (the protocol simply provides the 
mechanism to enable this to happen). We have therefore layered a protocol on top 
of SRM to maintain consistency of multiple views of a tuple space. This protocol 
relies on the use of a monotonically increasing logical tuple timestamps in order to 
allow detection of missing messages. The protocol also exploits the ability to 
snoop in SRM to improve the performance of the protocol. 

The benefits of this approach are that SRM is inherently scalable and highly 
efficient, being directly supported by IP multicast. The resultant platform is also 
portable to any network environment supporting IP multicast. The QoS 
architecture can also exploit existing Internet protocols for resource reservation. In 
particular, we assume the availability of RSVP (or equivalent) in our prototype 
implementation to provide QoS guarantees. This can then be supplemented by 
other QoS management functions such as admission control, monitoring and 
adaptation as described above. 



6 CONCLUDING REMARKS 

This paper has considered the role of QoS management in a mobile environment, 
where end systems are interconnected by heterogeneous networks. The paper argues 
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the emphasis of QoS management in such environments should be on support for 
monitoring and adaptation. Furthermore, the scope of QoS management should be 
extended to include a variety of environmental factors including the level of 
connectivity, the current cost of connectivity, power availability and rate of 
consumption, and the current physical location and time. 

We have described the Limbo distributed system platform which is intended to 
operate in a mobile environment. This platform is based on the tuple space concept 
and enables the creation of QoS-aware tuples spaces supporting admission control, 
resource reservation, monitoring and adaptation. This architecture can provide 
guarantees while underlying levels of connectivity remain fairly constant but also 
supports adaptation when significant changes occur for one or more end systems. 

The advantages of the proposed approach are i) guarantees can be offered as with 
conventional architectures (assuming a relatively stable network), ii) there is a 
single means of monitoring QoS, iii) all monitoring data is potentially globally 
available, iv) tuple spaces naturally support adaptation through mechanisms such 
as agent migration or replication, or selective tuple filtering, and v) tuple spaces 
accommodate periods of disconnection through the persistent nature of tuples. 
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Abstract 

Initially, Internet protocols were not designed for mobility nor were they de- 
signed for handling real-time services. Recent research efforts on Mobile-IP 
and RSVP are aimed at providing these features in the Internet. However, ad- 
ditional support is needed to provide real-time services for moving users. One 
such real-time service for mobile users is the concept of an Internet Cellular 
Phone. An IP based backbone network capable of delivering packetized voice 
to moving users. 
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1 INTRODUCTION 

This position paper argues for an architecture to support an Internet Cellular 
Phone network, a network that consists of an Internet backbone supporting 
a cellular phone network at the edge as shown in Figure 1. The edge network 
consists of base stations supporting IP cell phones or devices that can send and 
receive packetized voice and the backbone is the Internet. The base stations 
are connected to routers that support Mobile-IP routing (Perkins et al, 1996) 
and reservation protocols to guarantee service quality to moving users. 

Why an Internet cellular phone? Here’s why? We believe that determining 
the support protocols needed in the Internet to provide real-time service guar- 
antees to moving users is a significant research problem. Also, the problem 
of mapping existing cellular services as IP services is an interesting research 
issue. For example, the problem of providing a cellular conference call using 
Mobile IP Multicast (Acharya et al, 1996). Providing integrated services in 
the Internet to moving users allows additional capabilities: simultaneously re- 
ceiving e-mail while talking on the Internet Cellular Phone using the same 
network. 

Recent research efforts in Mobile-IP are aimed at supporting mobility in the 
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INTERNET BACKBONE 
IPv6 + MOBILE-IP + MRSVP 




Figure 1 Architecture for an Internet Cellular Phone Network 



Internet. Efforts in IPv6(Deering ei al 1995), RSVP(Zhang et al 1993) and 
Integrated Services( Clark ei al 1992) are aimed at providing quality of service 
support in the Internet. However, due to the significant impact of mobility, 
providing real-time services to mobile users requires new service architecture 
and new protocols. 



2 MOTIVATION 

When a mobile host moves from one location to another with an open connec- 
tion, the data flow path changes. As a result, the packet propagation time and 
the congestion delay along the new path may be different or the new cell may 
be so congested that the minimum QoS requirements of all users cannot be 
satisfied (Acampora ei al 1994, Lee 1995, Lu ei al 1996, Levine 1995). Due 
to handoff, additional delays and packet loss may occur (Caceres ei al 1996). 

In the fixed network, several classes of service, e.g. guaranieed, prediciive 
(Clark ei al 1992) and contro//ed-/oad(Wroclawski 1996), have been defined for 
real-time services. However, these service classes do not take into consideration 
the effects of mobility. There are two ways to provide QoS guarantees to mobile 
users. The first one is mobility independent, where a mobile user gets a QoS 
guarantee which is not affected by the mobility of the hosts. The second one is 
mobility dependent, where the QoS received by a mobile user may vary due to 
mobility of the hosts. To provide mobility independent service, it is necessary 
to make spaiial resource reservations; i.e., reservations at all cells where the 
host may visit in the duration of the connection. 
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3 ISSUES 

Based on the above observations, a network system architecture for providing 
real-time services to mobile users has been proposed in (Talukdar et al 1997). 
This architecture describes the service classes, admission control schemes, a 
reservation protocol, MRSVP, which is an extension of RSVP to handle mo- 
bile users, and the handoff management schemes. In this architecture, there 
are two service classes, mobility independent and mobility dependent. To ob- 
tain mobility independent service, a subscriber specifies its mobility specifica- 
tion^ the set of cells it may visit during the lifetime of the connection, to the 
network. The network reserves resources from the sender to all cells of the 
mobility specification. However, the data flow starts only to the current loca- 
tion of the mobile host. The reservation along the path from the sender to the 
current cell over which data is flowing is called active reservation, whereas the 
reservation along the paths to the other cells over which data is not currently 
flowing is called passive reservation. Subscribers to the mobility dependent 
service class makes reservation from the sender only to their current cell. To 
improve network utilization, the admission control scheme allows the resources 
of passive reservation to be used by the users of mobility dependent service 
class; however, when the actual reservers of those resources arrive into that 
cell, they may suffer degradation in QoS. 

In the rest of this section we identify the main issues in supporting an Inter- 
net cellular phone system on the framework of the above architecture. These 
are as follows: 

• Service commitments: We have defined two types of service contracts: mo- 
bility independent and mobility dependent. Defining other types of service 
contracts that can be met in spite of mobility is an open research area. 

• Mobility specification: It has been observed that, the movements of users 
have a regular component and a random component. Using these observa- 
tions, there has been some proposals for predictive mobility management (Liu 
et al. 1996). We believe that short-term mobility prediction for the duration 
of a call can be done using these techniques and further research is required 
in integrating mobility specification with spatial resource reservations. 

• Handoff management: The main approaches to reduce disruption during 
handoff are, multicasting the flow to neighboring cells of a mobile host, ex- 
tending the routes from the current cell to the next cell, anticipatory handoff 
to the next predicted cell and using retransmission buffers to recover from 
packet losses due to handoff (Caceres et al. 1996, Keeton et al. 1995). Handoff 
interacts with reallocation of resources, degradation of service and resource 
reservations. 

• Protocol integration: IPv6 (Deering et al. 1995) contains some unique fea- 
tures that provide some useful facilities to route data packets to mobile hosts 
efficiently (Perkins et al. 1996). In addition to features already present in 
RSVP, MRSVP protocol(Talukdar et al. 1997) requires several additional fea- 
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tures; e.g., active and •passive reservation, reservation by proxy agents to make 

spatial reservations for the different classes of services to mobile users. 
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1 INTRODUCTION 

The development of next generation mobile multimedia communications systems [2] 
presents a number of technical challenges which are thus far unresolved. First, it is 
essential that QOS assurances be given for the transfer of audio and video flows to 
mobile devices as they migrate between cells in cellular systems. Second, future mobile 
communications systems must be able to provide dynamic re-routing of a set of 
multimedia flows associated with a mobile device from one base station to another in a 
timely manner, without significantly interrupting the flows in progress and with a smooth 
change in the quality delivered. Third, existing multimedia transport systems are 
ineffective when operating in environments where widespread mobility and changing 
network characteristics are dominant. These challenges, due primarily to large-scale 
mobility requirements, limited radio resources and fluctuating network conditions, 
fundamentally impact our ability to deliver multimedia flows over mobile and, in 
general, QOS fluctuating networks. 

In this position statement we present a number of QOS challenges for next generation 
mobile middleware. Specifically, we address the need for QOS-aware middleware for 
mobile multimedia communications and illustrate one possible approach being 
developed in the wireless media systems [6] project at Columbia University. For an 
extended version of this position statements see the web [7]. 

2 QOS CHALLENGES 

A number of key questions need to be resolved when investigating QOS-aware 
middleware. First, what is the relationship between the middleware layer and the wireline 
and wireless network? The radio channel’s varying QOS characteristics and device 
mobility fundamentally impact our ability to deliver hard QOS guarantees in the wireless 
environment. Therefore, what is the level of QOS (i.e., service class) which can be 
ensured by the network to the middleware platform (e.g., hard, soft, or no guarantees)? 
Based on this result, what is a suitable QOS abstraction to offer to mobile multimedia 
applications? 
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Second, what is the impact of handoff on mobile multimedia flows? A flow with certain 
capacity reserved at a particular cell may have to be re-routed when the mobile device 
changes its location. The new path to the desired location may not have the original 
required capacity. Therefore, re-negotiation of resources allocated to the connection is 
needed. At the same time, the flow (e.g., audio or video) should be transported and 
presented ‘seamlessly* to the destination device with a smooth change of perceptual 
quality. 

Next, what is the ability of the mobile multimedia applications to adapt when resources 
fluctuate over time. This is dependent on the type of flow. For example, continuous 
media flows have built-in redundancy where media scaling algorithms can exploit the 
intrinsic scalable properties of multi-resolution audio and video flows when the delivered 
QOS fluctuates. 

Fourth, audio and video flows are characterized by the production, transmission and 
consumption of single media streams (both unicast or multicast) with associated QOS. 
For multicast flows, individual receivers (both wired and wireless) may have differing 
capabilities to consume flows. This could be due to either fluctuating network resources 
with mobility or imposed by individual applications. How do we bridge this 
heterogeneity gap in mobile multicast environments while simultaneously meeting the 
individual mobile devices* QOS requirements? 

In order to clarify these issues and put them into the proper perspective, we present a 
brief description of one platform which addresses these QOS challenges. The mobiware 
platform sets the stage for a brief discussion of the type of new architecture and 
algorithms needed to realize next generation mobile middleware 

3 MOBIWARE: QOS-AWARE MOBILE MIDDLEWARE 

Mobiware is a software middleware platform that runs seamlessly on mobile devices, 
base stations and mobile-capable ATM switches based on xbind [3] programmability. 
As illustrated in figure 1, mobiware operates in the region between the radio and wired 
ATM communications firmware, and mobile multimedia applications. The goal of QOS- 
aware middleware is to provide a highly programmable platform for delivering 
continuous media flows in mobile multimedia networks. The concepts of 
programmability [3] and adaptability [1] are central to managing the complexity of 
delivering voice, video and data with high quality over QOS-varying mobile networks 
during handoff and periods of persistent QOS fluctuation. The mobiware platform is built 
on xbind (built itself on CORBA technology) and Java distributed systems technology 
and incorporates new architecture and novel adaptive algorithms to support the concept 
of ‘QOS controlled mobility*. 

Mobiware provides mobile multimedia applications with a new QOS abstraction called 
QOS controlled mobility. This involves scaling flows during handoff rather than 
dropping them when desired resources are unavailable. The benefits of such an approach 
is to reduce handoff dropping and improve wireless resource utilization. We use the term 
“controlled QOS** to distinguish it from hard QOS guarantees offered by fixed ATM 
networks. Implicit in the term is the notion that flows can be represented and transported 
as multi-layer scalable flows at the mobile device as illustrated in figure 2. Adaptive 
algorithms help scale flows during handoff based on available bandwidth and an 
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application-specific ‘flow adaptation policy’ [1]. This policy characterizes each audio 
and video flows as having a minimum QOS layer and a number of enhancements. 
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Figure 1: Mobiware 

Mobiware is built on three major algorithmic components: First, QOS controlled 
mobility, is based on the seamless delivery of media through interaction with an adaptive 
network service, media scaling objects, and an adaptive and active transport system 
called a-trane; the handoff algorithm employes advanced algorithms which model flows 
using mobile soft-state, aggregate flows using the concept of connection groups and limit 
the impact of small scale mobility of the wired network through the introduction of local 
anchor points for routing and adaptation - for full details of the handoff algorithm see [5] ; 

Next, an adaptive network service, characterizes flows as having a base layer (BL) and 
a number of enhancement layers (viz. El and E2). The base layer provides a foundation 
for better resolutions to be delivered through the reception of enhancement layers based 
on the availability of resources in the wireless environment - for full details on the 
adaptive network service which offers hard guarantees to the BL and uses QOS 
adaptation for enhancement layers see [1]; and 




Figure 2: QOS Contndled Mobility 
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Finally, adaptive and active transport called a-trane, supports the transfer of multi-layer 
flows through the provision of a QOS-based API and a set of dynamically loadable active 
transport objects (ATOs) (e.g., active filters [4] and error control objects [1]). Dynami- 
cally loadable transport objects can be dispatched to the base station and mobile devices 
to support valued-added QOS when and where it is needed e.g., during periods of QOS 
fluctuations and degradation. Currently mobiware supports active filters and error con- 
trol ATOs - for full details on a-trane see [6]. 
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Abstract 

This paper examines the transmission of MPEG video over high error rate links such 
wireless links. We present results showing the effect of transmission errors on MPEG 
streams and suggest an algorithm based on a combination of Forward Error Correction 
(FEC) and Automatic Repeat Request (ARQ) as a way to minimize its effects. We introduce 
a packet tagging technique that takes into account the particular semantic of MPEG flows to 
explicitly tell the network, both wired and wireless, which packets should necessarily be 
delivered correctly. 

Keywords 
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1 INTRODUCTION 



The proliferation of portable computers with wireless capabilities together with the 
deployment of higher bandwidth wireless links is making it possible to extend video 
applications to wireless users. The Moving Picture Expert Group (MPEG) is becoming the 
standard video coding technique for most applications in the multimedia world. However, 
MPEG presents two big disadvantages for transmissions purposes over telecommunications 
networks. These problems are related with the periodic peaks in its bit rate due to the use of 
different compression techniques on consecutive pictures (Intraframe I pictures and 
Interframe P and B pictures) and also because of the difference in image quality perception 
of different types of pictures. In other words, the MPEG video stream is not constant in a 
quantitative way (bit rate), and neither in qualitative way (picture type). The inherent 
characteristics of wireless links, specially the higher error rates, will introduce a complete 
new set of issues that need to be taken into account in order to provide a reasonable QoS. 

2 ERROR RATE ANALYSIS 



So far, transmission of MPEG video streams has been studied over protocols that are 
designed with links of high reliability and where packet losses are mostly due to congestion. 
However, in wireless links packet loss is mainly a result of high bit error rate of the medium 
and this will drastically deteriorate received picture quality. In order to test the effect of 
wireless link errors on MPEG streams we used the following model: 




Figure 1. Wireless link error simulation testbed. 
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In our test-bed, the original video frames are encoded using MPEG-1 and packetized into 
ATM cells (48 bytes). In order to isolate the error behavior of the system we assume that no 
contention for access on the wired link occurs and the necessary bandwidth in the network 
is always available to the video stream. The error generation module at the base-station uses 
an exponential error distribution to simulate errors over the wireless path. The video source 
we use is a MPEG-1 sequence of the film Ben-Hur with a Group Of Pictures (GOP) 
sequence IBBPBBPBBI. The bit rate of the video is 500 Kbps. In our experiments we test 
the two most common type of errors that occurs in wireless links. These types of errors are: 

Fast fading: Fast fading causes the strength of the signal to vary rapidly with time. This 
may result in single bit random errors. For this source of errors and a bit error rates of 10 ^ 
there is not a noticeable effect on the quality of the video at the receiver. Since most part of 
the encoded video stream is Discrete Cosine Transform coefficients (DCT), a DCT 
coefficient in error does not have a big impact on the overall quality of that particular group 
of pictures. However, for an error rate of 10^ the situation changes drastically. For this error 
rate many control fields were corrupted by errors. These errors are enough to completely 
distort about 10 to 20 percent of the macroblocks per picture (refer to figures 2 and 3). 
When errors are introduced but just in the first bytes of the video stream, the whole session 
crashes and nothing appears on screen. The errors detected in the decoder happen to be 
related with information in the header of the video stream, which we refer to as control 
packets or control fields. The header contains the most important parameters for the MPEG 
decoder to work properly. As it is easy to understand control fields of the MPEG header 
should be strongly protected against link errors, and the strongest error correction care 
should be used here. In case that still some of the control fields were corrupted the decoder 
should ask for a retransmission. 




Figure 2. Picture 1 (I picture) Figure 3. Picture 4 (P picture) 



Results of these tests clearly suggest that it is the type of field in error, which for the most 
part decides the level of damage in the quality of video rather than simply the raw bit error 
rate. The problem now is that we need to protect control packets against transmission errors 
much more than others in order to achieve a reasonable quality of video at the mobile 
terminal. 

Slow fading (shadowing). In the presence of slow fading the strength of the signal changes 
slowly with respect to time and this will cause bursts of errors. For this source of errors we 
assume that a entire cell can be corrupted even if Forward Error Correction data is attached 
to the packet. The main effects appearing in this case are mostly the same as in single bit 
random errors. The loss of a packet containing DCT coefficients has almost no effect on the 
overall quality of the video. However, the loss of a packet containing control fields will 
drastically deteriorate the quality. 

Since different type of pictures will be delivered to the mobile terminal, it is important to 
understand how the video degrades when errors corrupt different type of pictures. For 
picture level tests we only introduce errors in a single picture to see the propagation effect 
of these errors in following pictures. In the first test we introduce errors but just in the first 
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picture of the group of pictures (I picture). These errors will corrupt some macroblocks in 
that picture that remains during the following P and B pictures (refer to figure 3). The 
reason is that P and B pictures are decoded with respect to the previous I or P pictures. This 
issue makes it imperative to protect I pictures with a stronger FEC algorithm or by using 
retransmissions. If the I picture is completely corrupted it is no sense to transmit the rest of 
the group of pictures, since all the information in the remaining pictures will be useless at 
the mobile terminal. 



In the second test, errors do not corrupt packets in I pictures, but errors will corrupt P 
pictures. Common errors we got are mostly DCT coefficients out of range that introduce 
dark spots on the screen that in some sense may be tolerable. However, protecting I pictures 
against link errors improve the quality of the video noticeably. Some times dark 
macroblocks appear and remain on the following pictures if errors hit P pictures 
macroblocks that are used as reference by the followings P and B pictures (figure 4). This 
suggests that important control fields of P pictures should be also guaranteed an error-free 
delivery. 



Since B pictures need one of the previous pictures and one of the following pictures to be 
decoded they require out of order transmission. For these reasons B pictures are not suitable 
for real time applications. Therefore a sequence of MPEG may have only intraframes 
pictures (1 1 1 1 1 1 1 1) or may contain intraframe/interframe pictures (I P P P P P P P I). In a 
mixed Intraframe/interframe scenario except for the first picture, the remaining pictures (P 
pictures) need the previous picture to be decoded. This means that if errors hit one picture 
macroblock in the i th. picture, that error will also appear in picture i+1, i+2, i+3 ... N-i, 
where N is the number of pictures in the group of pictures. As a result, one macroblock in 
error is going to remain on the screen until a new I picture arrives to the decoder. Knowing 
this, the mobile terminal can, if necessary, request the encoder to increase the ratio of 
intraframe to interframe pictures so corrupted blocks will just propagate a maximum of N-1 
pictures. 



Reducing the number of P pictures among I pictures will noticeably increase the bit rate but 
this can be compensated with a bigger step size when quantization is taken place at the 
encoder. In the case that bandwidth is still a limitation to support more I pictures, the 
encoder might even reduce the picture rate to compensate for the additional I pictures bit 
rate. The basic design criteria will be that it is better to show few good pictures per second 
in the mobile terminal rather than show many bad pictures. 



0 Due to link errors 



PictureType: P 



^ Decoded erroneously 

Figure 4. Propagation of errors in a GOP 




Another way to overcome slow fading situations will require the source to slow down its 
transmission rate (say reduce the picture rate) so the Bit Error Rate (BER) decreases to a 
point where FEC alone is again enough to kept and acceptable video quality. However, the 
time involved in telling the source to decrease the bit rate and the time the mobile terminal 
can start seeing the effects will take to long. For these reasons we consider that an ARQ 
capability should still remain to allow retransmission of important packets that might 
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become lost in the air. This leads to a hybrid FEC/ARQ error correction protocol to 
overcome single and packet level errors 

Because of the potential long time propagation delay involved, we propose to snoop the 
connection at the base station so the retransmission times are much shorter allowing ARQ 
protocols to be more effective. This implementation makes it necessary to buffer the MPEG 
packets at the base station until acknowledgments are received from the mobile terminal. 
However, as we mentioned in the previous discussion, not all the packets need to be 
forcefully received correctly. In this case we propose to mark important control packets 
with a flag that guarantees that those packets will be delivered correctly (packets that may 
be buffered and re-transmitted if necessary). This can be done by increasing even more the 
EEC error capacity or/and by retransmissions [4]. Other packets (mainly packets with DCT 
coefficients) will not be tagged with the flag. 

Marking each packet with a flag (potentially more than one bit) makes the network 
understand the semantic of MPEG in order to maximize the quality of the video at the 
mobile terminal even if congestion and transmission errors occurs. The penalty is that now 
the application layer at the encoder should be modified to send priority information to the 
transport layer in order to set the flag in each packet. At the same time routers along the 
path (at least the base-station) should look inside the packet to read and process the flag. 

For picture level errors we propose to mark all the packets belonging to I pictures so that 
these packets will reach the mobile correctly with an acceptable high probability. It also has 
to be guaranteed that packets containing important fields of P pictures reach the mobile 
correctly. Finally, depending of the error rate behavior at any particular time, we may 
dynamically increase or reduce the number of P pictures between I pictures. 

3 CONCLUSIONS 

We showed the effects of high error rates on MPEG streams pointing out some ways to 
compensate for these errors. Also, we show that for the most part, it is the type of field in 
error which determines the level of damage to the quality of the video rather than the raw 
bit error rate only. It is important to preserve an ARQ capability at the base-station in 
combination with common FEC techniques as a way to compensate for both, the high error 
rate characteristics of the links and the impact in image quality of different type of pictures. 
We also discussed the advantages of periodically sending feedback information to the 
source to readapt to changes in the network. 
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Abstract 

In recent years small, completely portable computers have become available 
on the marketplace. There is demand for such computers, termed walksta- 
tions, to access network services while retaining their mobility and to operate 
effectively whilst traversing both indoor Wireless LAN (WLAN) networks and 
the outdoor Mobile Radio Network (MRN) infra-structure. 

This paper introduces the traded handoff where connections are rebuilt dur- 
ing a handoff to the most appropriate service, taking into account the prop- 
erties required by the application and locally available, replicated or compat- 
ible services. Network level solutions can only redirect connections back to 
the original endpoint as the walkstation moves. This is the case even if the 
connection is to a locally replicated service. 
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1 QUALITY OF SERVICE SUPPORT 

The trading-space visible to an application potentially contains the offers 
from a number of federated traders corresponding to different network types, 
providers, or gateways. When trading for offers in this environment, a client 
may wish to place additional constraints on the offer based upon the Quality 
of Service (QoS) obtainable. For example, to minimise the cost of communi- 
cation. Such constraints do not relate to properties of the service exported by 
the server, but instead to properties of the service which would be received 
by an application given the current and expected behavior of the walkstation. 
It would therefore be impossible for an offer to contain these properties when 
exported. 
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Figure 1 QoS Constraints. 

Since it is not possible to determine the exact QoS available for a particular 
offer without direct negotiation with the exported server interface, a heuristic 
is used during trading: offers from federated traders are matched only if the 
QoS experienced between the federated traders matches the QoS constraints 
from the client. This may be illustrated by the trivial example shown in Fig- 
ure 1. Here, the walkstation is federated with two traders, Ti and T 2 , over 
links with respective Cost of 40 and 70. If the walkstation’s client queries its 
trader with the constraint: 

{Cost < 100 and Service = A) or {Cost < 50 and Service = B) 

The walkstation’s trader considers the QoS available to each of its federated 
traders Ti and T 2 and sends a request to trader Ti with constraint: 

{Cost < 60 and Service = A) or {Cost < 10 and Service = B) 

and to trader T 2 with constraint: 

{Cost < 30 and Service = A) 

The second or clause is dropped in the request to trader T 2 , since it requires 
a link of Cost < 50 and the link to trader T 2 has a Cost of 70. These queries 
result in the list of returned offers: {{T\ : A,B), (T 2 : -A)). The walkstation’s 
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trader inserts the appropriate values for the Cost QoS property to each of 
these offer’s property lists so that they are considered by the client. 

The above example has illustrated a case where the QoS properties are 
cumulative over a route. The sum of the cost over each link must be no 
greater than the total specified in the constraint. Other QoS properties, such 
as Bandwidth are not. Non-cumulative properties are passed unmodified over 
each link. 

If the same server instance is available through a number of different routes, 
the corresponding offers returned to the client must be distinguishable. In 
some circumstances, this may require the modification of the returned inter- 
face references by the walkstation’s trader. 

By propagating the QoS constraints in the queries to federated traders, each 
trader in a chain of federated traders is able to consider the constraints and 
the QoS available between itself and the next trader, and so perform further 
restrictions on the query. 

What the trader cannot do is to negotiate precise QoS parameters for a 
particular service. These will vary over a particular network and over time 
at the same base station, dependent upon factors such as signal quality and 
the number of walkstations simultaneously using a particular base station. An 
application must negotiate its own QoS at the time a binding is established. 



2 THE TRADED HANDOFF INTERFACE 

A program module which is to explicitly use the traded handoff mechanism 
is expected to provide an implementation of the Handoff Interface (HDI), 
and its three constituent methods: Open, Unmount and Mount The Open 
method requires the module to create and stash all its required bindings to 
servers. The Unmount method requires a module to close down its bindings 
and block its threads at one of a set of well defined synchronisation points. 
The Mount method requires the module to initiate a new session with the 
server using the stashed bindings, transferring appropriate client state. The 
module’s threads (if blocked) may at this point continue. The example shown 
in Figure 2 illustrates how the traded handoff is performed for a client. 

To utilise the full potential of the traded handoff, it is essential that the 
end-application is given the opportunity to transfer it’s session level state. 
For example, a video server application might be initialised with the title 
of a video to be played together with a frame offset. Assuming that a more 
appropriate video server is visible in the trader after a handoff, the new video 
server should be initialised with the required title and offset as part of the 
Mount phase. 

However, where the application wishes to use a default behavior or where 
the application is unaware of traded handoflfs, the Remote Procedure Call 
(RPC) package provides an implementation of the HDI and directly responds 
to traded handoflf requests. Applications which are aware of the traded handoff 
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Figure 2 Blocking During a Traded Handoff. 



may specify a default behavior of either re-establishing bindings to the original 
server interface or to another server which matches a given constraint. For 
applications which are unaware of mobility, the RPC package responds by 
re-establishing bindings only to the original interface. This enables the use of 
legacy code in an environment which relies on traded handoffs. 



3 CONCLUSION 

This paper has introduced the traded handoff, enabling widely replicated ser- 
vices and heterogeneous networks to be utilised as a walkstation is carried over 
large distances. The handoff protocol described here has been implemented 
and integrated with an object based RPC package [2] and trader which im- 
plements a subset of [1]. Experience in the local area has demonstrated the 
traded handoff for a number of applications including a network based video 
server. In this case, the disruption experienced by the end viewer (13ms) was 
much less that the play out time for a frame of video and indicate that use of 
the traded handoff in the wide area is feasible. 

Future directions for this work would involve the use of a mobile infra- 
structure using walkstations over multiple wireless network types and in the 
wide area. 
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Abstract 

We have simulated a set of independent connections limited by leaky bucket 
shapers and fed into a buffered multiplexer. This scenario is typical of an ATM 
switch or in a looser sense of an RSVP capable router. We found periodic 
traffic patterns which result in much worse loss rates than the on-off or tri- 
state patterns found in literature to date. We give an intuitive justification 
for what we believe is the worst case and back this with an extensive set of 
simulations. Our results are important for Connection Acceptance Control 
when connections are known to be statistically independent. They clearly 
invalidate the widespread belief that on-off patterns are the worst case traffic 
of independent leaky bucket constrained sources. 

Keywords 
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1 INTRODUCTION 

The leaky bucket traffic descriptor has been chosen as the traffic descriptor 
for ATM networks and in a looser sense in the integrated services Internet. 
The advantage of the leaky bucket is that it makes it easy to verify whether 
a source conforms to its traffic descriptor. However, it is very difficult, given 
the leaky bucket parameters, to estimate the exact amount of resources that a 
set of connections will require. This information is needed at connection setup 
time to know whether a new connection can be accepted or not. This is the 
problem of Connection Acceptance Control (CAC). 

A recent overview of existing CAC schemes is given in (Perros and Elsayed 
1996). The goal of a good CAC scheme is to accept as many connections 
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as are possible without disrupting the contracted Quality of Service (QoS) 
of accepted connections. Most CAC schemes make some assumptions about 
traffic, in order to be able to estimate the resources required by a connection. 
The most common assumption is that traffic in each connection conforms to 
a given stochastic process, usually some kind of on-off process. 

In this paper we make no assumption about the traffic. Each connection 
may thus have an arbitrary distribution. The only assumption we make is that 
in each connection the traffic conforms to the declared leaky bucket param- 
eters. Furthermore we assume that the connections are independent of each 
other, in other words that there is no correlation between them. Typically, 
connections can be assumed independent when they are unrelated (eg. orig- 
inating and terminating at different hosts) and when the network does not 
introduce artificial correlation. 

Under these assumptions we try to find the maximum loss rate which can 
occur in a multiplexer given the leaky bucket parameters of all connections. 
In particular we try to find the worst kind of input traffic (referred to as the 
worst case) which leads to the maximum loss rate. 



1.1 Existing work 

It is a common belief that on-off sources are the worst case of indepen- 
dent, leaky bucket constrained sources, as in (Kositpaiboon and Phung 1990), 
(Rathgeb 1991), (Kvols and Blaabjerg 1992), (Worster 1994), (Johri 1995), 
(Elwalid, Mitra and Wentworth 1995) and (Presti, Zhang, Kurose and Towsley 
1997). This is due to the fact that on-off patterns have the highest variance 
of all possible patterns and because of the assumption that a higher variance 
always leads to a higher loss rate. However, (Doshi 1994) and (Yamanaka, 
Sato and Sato 1992) have shown counter examples where a pattern called 
tri-state pattern results in more loss. In (Worster 1994) the author points to 
some possible flaws in (Yamanaka et al. 1992) and tries to re-establish that 
on-off patterns are the worst case. 

For the case of correlated, leaky bucket constrained sources exact solutions 
for delay and queue-length bounds have been found. First results can be found 
in (Cruz 1991), with an extended and more elegant form in (Le Boudec 1996). 
An example of worst case patterns for correlated traffic based on these results 
can be found in (Lee 1994). 



2 THE EXPERIMENT 

We consider a multiplexer with N incoming connections, all described by their 
leaky bucket parameters m for mean rate, p for peak rate and b for burst size. 
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Figure 1 the multiplexer 



The multiplexer has a FIFO buffer of size X and outputs its traffic on a link 
with capacity ^ For reasons of stability p must be smaller than 1. 

We consider the homogeneous case where all connections have the same 
leaky bucket parameter. We apply a deterministic periodic pattern to all in- 
puts of the multiplexer and measure its average loss rate. The loss rate is 
defined as the amount of data lost due to buffer overflow, divided by the 
amount of data offered to the multiplexer. Since the same pattern is applied 
to all inputs, the only difference between the traffic in the connections is the 
phase of the patterns. The connections are assumed to be independent and 
thus the phases have a uniform random distribution. 

For this experiment we have chosen following conditions: AT = 20, p = 5, 
m = 1, 6 = 20, and p = 0.99. Traffic is assumed to be fluid and the discrete 
size of packets is not taken into account. The effect of packetization can be 
made arbitrarily small by using adequate units for the different parameters. 



2.1 Traffic Patterns 

The traffic patterns used in our simulations are derived from the on-off pat- 
tern. An on-off pattern consists of a burst at peak rate with size 6, followed 
by a silence of duration 6/m after which a new burst can be sent. We derive 
new patterns from the on-off pattern and express their difference by a form 
factor, f ov g. We report the results for the following patterns: 



on_off 

p 

m 

0 ^ 

b ^ ^ T 

p—m m 



The maximum allowed burst followed by the 
shortest period of silence allowing a new burst. 
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trijstate(/) 



/ 



shift(/,5) 

" 7 " 



sym(/) 

" 7 " 



An on-ofF pattern with an inserted plateau at 
mean rate between the burst and the silence pe- 
riod. / denotes the total duration of the pattern 
in units of the on-off pattern. Hence tri_state(l) = 
on_off. 

The shift pattern takes a tri.^tate pattern and 
shifts the burst to a point between the begin- 
ning and the end of the plateau, g denotes the 
time between the beginning of the pattern and 
the beginning of the burst in proportion to the 
length of the plateau. We thus have 0 < ^ < 1 
and shift(/, 0) = tri_state(/). 

Sym is a symmetrical pattern which corresponds 
to an on-off pattern with two identical plateaus 
inserted before and after the burst. / denotes the 
length of the pattern in units of the the length of 
the on-off pattern. We have sym(l) = on_off and 
sym(/) = shift(/, i) 



2.2 Simulation Results 

We now describe the results obtained from the simulations. All plotted results 
have a 95% confidence interval smaller than ±5% of their value. Figure 2 
shows the loss rate in the multiplexer as a function of its buffer size. We fix a 
reference point at buffer size 180. At this point we see that the average loss 
with on-off patterns is about 2.2x10"^. 

Figure 3 shows the loss rate at the reference point for tri_state patterns as 
a function of the form factor /. As hinted in the literature we find that the 
loss rate can be higher than for on-off patterns. Note that tri-state(l) is equal 
to on.off , thus for / = 1 the loss rate of tri_state is the same as for on_off . We 
see that for small / the loss rate initially increases. It reaches a maximum of 
1.05x10“^ at / = 1.4. trijstate patterns can thus be worse that on.off ones, 
in the particular case by almost a factor of ten. 

Based on the worst trijstate pattern mentioned above we next investigate 
the effect of shifting the burst. Figure 4 shows the loss rate as a function of 
the form factor of shift (1.4,^). We see that the curve is symmetrical and that 
the loss rate is maximal when the burst is in the centre of a plateau at mean 
rate. This finding motivates the next simulations using the sym pattern. 

Figure 3 shows the loss rate for sym(/) as a function of the form factor /. 
Again sym(l) = on.off and the loss rate at / = 1 is the same as for on.off. 
For / = 3.5 the loss rate reaches 1.05x10”^, yet another factor of ten above 
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Figure 2 loss rate as a function of buffer size for selected patterns 




Figure 3 loss rate for trijstate pattern as a function of / 



the maximum loss rate of the trijstate pattern. Also, we see that after the 
maximum the loss rate does not decrease as rapidly as it does for the trijstate 
pattern. We will explain this effect in the next section. 

Figure 2 also shows the loss rate as a function of the buffer size for trijstate (1.4) 
and sym(3.5). We can see that for buffer sizes greater that 100 tri_state(1.4) 
and sym(3.5) are worse than the on.off pattern. Note that the / which max- 
imises the loss rate depends on the buffer size, thus sym(3.5) is only the worst 
case for a buffer of size 180. 
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Figure 4 loss rate of shift(1.4,5f) as a function of g 



3 DISCUSSION 

Let us first introduce the notion of a full rate multiplexer. We speak of a full 
rate multiplexer when the sum of the mean rates of its inputs is equal to its 
output rate {p = 1). Furthermore we define the set of full burst sources as the 
set of periodic sources which have plateaus at the mean rate m, one burst of 
size 6 at a rate between m and p and one period of ’rest’ where they send at 
a rate smaller than m until the burst is compensated for. Note that all the 
patterns investigated belong to full burst sources and that full burst sources 
have a mean rate of m. 

Consider a full rate multiplexer fed by N independent periodical full burst 
sources. The set of sources can be seen as N sources sending continuously at 
their mean rate plus N sources sending positive and negative bursts of size 6. 
A single positive burst will occupy 6 amount of buffer space in the multiplexer. 
Since in absence of bursts the output rate of the multiplexer is equal its input 
rate, the buffer occupied by that single burst will only be released when a 
negative burst occurs. Full burst patterns all have alternating positive and 
negative bursts of the same size. Now define the centre of the bursts as the 
point in time where half of the burst has been transmitted. Call the interval 
between the centre of a positive burst and the centre of the following negative 
burst <&i. Call the interval between the centre of the negative burst and the 
centre of the next positive burst Consider the case where n positive bursts 
need to add up to overflow the buffer. Their centres need to be within a period 
smaller than to avoid the last positive burst being cancelled by the negative 
burst following the first positive burst. The centre of the bursts also need to 
occur in an interval smaller than $o- H not, the preceding negative burst of 
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the last positive burst falls into the interval. Thus for the buffer to be occupied 
by at least n bursts, n or more bursts must occur within min(^i,<^o)* 

The above does not consider the cases where positive and negative bursts 
partially overlap. To study this effect let us introduce one last pattern, delta(/). 

delta(/) I Instead of having positive and negative bursts at 

peak rate and zero, delta(/) has bursts of bS(t) 

^ L and —bS{t) where 6 is the burst size and S{t) is 

^ Dirac’s impulse function. / is the length of the 

pattern measured in the length of the original on- 
off pattern and both burst are distant of ^ from 
each other. 

For the delta pattern, the loss per period only depends on the buffer size X 
and not on the period /. Indeed changing / has no effect on the shape of the 
pattern itself and thus on the probability of buffer overflow. We have 

E'poss per period] = 1{X) 

On the other hand, the loss rate is inversely proportional to the period since 
the same loss occurs for every period. We thus have: 

Eposs rate] = 




Figure 5 loss rate of the full rate multiplexer 



The only difference between the delta pattern and the sym pattern is that 
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the bursts of the delta pattern cannot overlap because they have zero du- 
ration. Thus we can attribute differences in loss rate between the delta and 
sym patterns to the overlap of positive and negative burst in the connections 
with sym patterns. Indeed, consider two sets of delta and sym patterns with 
identical distribution of phases. If in the set of sym patterns there is no over- 
lap of any positive and negative burst, then the sym patterns will produce 
exactly the same amount of loss. However, if a positive burst overlaps with a 
negative one, then the bursts will reduce each others effect. If that positive 
burst participates in the loss produced by the set of sym patterns, then the 
loss will be reduced. 

To verify the above statements we have simulated the case of the full rate 
multiplexer with delta, sym and trijstate sources. The results are in figure 
5. Note the linearity of the loss rate of delta(/) which confirms its inverse 
proportionality to /. As expected the loss rate of sym(/) converges asymptot- 
ically towards delta(/) as / increases and the relative duration of the bursts 
decreases. 

We now come back to our general non-full-rate multiplexer to explain a 
final effect of / on the loss rate. In a non-full-rate multiplexer the output rate 
is larger than the mean input rate. If all inputs send at mean rate and one 
burst is received, this burst will occupy buffer space only for a limited time. 
The buffer will be cleared at a rate equal to the difference between the output 
rate and the mean input rate. This adds another constraint on the series of 
bursts adding up to overflow the buffer. The longer the period during which 
the bursts accumulate, the more will their effect be attenuated by the extra 
output rate of the multiplexer. Thus increasing the period of a pattern - even 
when its shape is not modified, as for delta - reduces its loss per period in a 
non-full-rate multiplexer. 



3.1 Summary 

We have explained the following effects: 

1. For full burst patterns, bursts can only accumulate if they happen in in- 
tervals shorter than min($i,$o)- 

2. Patterns with shorter burst lengths compared to their period have a smaller 
probability of overlapping burst and can thus generate more loss per period. 

3. For the same loss per period, the loss rate is inversely proportional to the 
period of the pattern. 

4. An output rate larger than the sum of the mean input rates reduces the loss 
rate of patterns with long periods more than the ones with short periods. 

Effect 1. is the reason why in all our simulations sym patterns generate more 
loss than trijstate patterns with the same /. Indeed min($i, $o) = = 1/2 
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for the tri^tate patterns, whereas it is equal to f/2 for sym. In other words, 
trijstate patterns produce less loss because there is always a negative burst 
immediately preceding positive bursts, thus preventing longer series of positive 
bursts to add up. Effect 4. explains the difference in simulations of the original 
multiplexer and the full rate multiplexer. Both loss rates of trijstate and sym 
decrease faster with / in the original multiplexer as in the full rate multiplexer. 
Finally, the opposite effects of 2. versus 3. and 4. are the reeison why there is 
a maximum loss rate for some / = /max- 

sym{fmax) is the worst case pattern of the class of full burst patterns since 
it maximises min($i,$o) by having = $o = 2 ’ i^iiiiniises the probability 
of overlapping bursts by having the shortest allowed bursts (at peak rate and 
0) and balances effects 2. against 3. and 4. by having / = fmax 

Note that on_off is a special case of sym and that it can be the worst case 
when fmax = 1- This could for example be the case in a very under-loaded 
multiplexer (exacerbating effect 4.) or when the burst size is small compared 
to peak and mean rate (reducing effect 2.) 



4 CONCLUSION 

We have shown in simulations, that sym patterns can generate significantly 
more loss than on_off or tri_state patterns. We have shown four different effects 
which explain the results of the simulations. Due to these effects the sym 
pattern is shown to be the worst case within the class of full burst patterns, 
which includes on_off patterns. 

Our simulations definitively invalidate the belief that on-off sources are 
the worst case for independent leaky-bucket constrained sources. This has an 
important consequence on existing CAC schemes. Indeed, any CAC scheme 
which is based on the assumption that sources behave like a given on-off 
process may grossly underestimate losses if the sources chose to behave like 
the worst case we have identified. 

The sym pattern we propose is not as easy to use as the on-off pattern since 
it has an additional parameter, the form factor / and we do not yet have an 
analytical way of finding fmax which will maximise the loss. 

Further interesting questions are whether there exist worst case patterns 
outside the set full burst patterns and what the worst case pattern is in the 
heterogeneous case, where connections have different leaky bucket parameters. 
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Abstract 

This paper presents a cell access control scheme for guaranteeing multiple classes of 
cell loss QoS (Quality of Service) requirements in an output buffer of ATM switch 
which is shared by multiple connections. First, we propose a class acceptance con- 
troller which regulates the acceptance of the cells of QoS classes based on the state 
of the queue. We consider decision functions for the class acceptance controller with 
a view to compare their effects to the QoS performance. After that, we present a 
queueing analysis and derive some important performance measures. Finally, we 
discuss the implications of the work via numerical experiments. 

Keywords 

ATM networks. Quality Of Service, Priority control 

1 INTRODUCTION 

The B-ISDN (Broadband Integrated Services Digital Networks) technologies based 
on ATM (Asynchronous Transfer Mode) cell transfer made it possible for various 
kind of media data to be provided simultaneously in the networks. Typical QoS 
parameters regarding the ATM sources are the maximum delay, peak-to-peak CDV 
(Cell Delay Variation) and the cell loss rate (CLR)[3]. The delay and its variation 
are required to be tightly guaranteed for RT-VBR (Real-time Variable Bit Rate) 
source, whereas RT-VBR can tolerate a very small value of cell losses. 

Since different services in the same RT-VBR require different QoSs, such as the 
cell loss and delay, the network has to guarantee these different QoSs simultaneously 
and transparently to the effect of the other services. 

The maximum cell delay requirements can be guaranteed by providing a finite 
queue capacity. On the other hand, the finite system can meet an overflow even if 
we dimension the queue capacity based on a conservative estimation because the cell 
input to a buffer is bursty, thus the guarantee of loss rates requires a sophisticated 
control scheme in the queue before the overflow occurs[8]. In this paper, we mainly 
consider the cell loss QoS requirements. The cell loss QoS requirement indicates 
that the mean cell loss of each class due to buffer overflow or any errors must be 
kept under the target value. 

One method to avoid the buffer overflow is to drop cells prior to the occurrence 
of it by setting one or more thresholds in a buflFer and discard a portion of cells 
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when the queue length exceeds the threshold[5]. In discarding cells, it is favorable 
for a system to provide a control scheme to drop all cells of one packet or one 
class rather than to randomly drop cells belonging to different packets or different 
classes[l]. This corresponds to the class acceptance scheme which we had proposed 
in the previous work [6]. 

Turning to the queueing policy, there axe two general ways to accomodate the 
cells of different classes of QoS[2]. One is to provide a separate queue for each class[9], 
which is usually called a Separate Queue (SpQ) scheme^ and the other is to provide 
a single queue shared by all the classes, which is called the Shared Queue (ShQ) 
5cheme[5,10]. Among them, the ShQ scheme can improve the buffer utilization by 
sharing the queue space, and it is free from the resequencing problem. Thus, the 
ShQ scheme is more favorable for real-time communication environments. In order 
to guarantee multiple classes of QoS using ShQ scheme we need a sophisticated 
cell admission scheme based on the priorities such as the Push-Out (PO) scheme 
or the Partial buffer Sharing (PbS) scheme[5]. The PO scheme and PbS scheme 
are considered and their performance is compared in detail in [7]. Among them, 
PbS scheme is considered to be more favorable since it is easy to control and easily 
implement able. In PbS scheme, the queue space is divided logically into multiple 
subspaces and it is partially shared by classes based on the queue occupancy at 
the cell aurrival instant. The basic principle of PbS scheme is described as follows: 
When there are QoSs of K classes, one can divide the queue space B (cells) into K 
subspaces (regions). Whether cells of each class can be accepted or not is decided 
by the state of the queue at its entering instant : that is. When the queue occupancy 
is in the range [7i,T»fi], i = l, . . . , K — 1,Tk =B, upon arrival of cells, only cells of 
classes not lower than class K — i is allowed to enter the queue, whereas the other 
classes are rejected and cells included in those classes are discarded in that time slot. 

In this paper, we consider the same PbS scheme. Upon determining the de- 
cision function, we propose a new method: first we set a base threshold, next we 
determine calibrating thresholds (the discussion in detail will be given in section 
3). We assumed five cell loss classes, which is based on the linguistic representation 
of the degree of stringency of the cell loss requirement: very stringent, stringent, 
moderate, loose, and very loose. 

2 SYSTEM MODEL 

Let us consider an output multiplexer of ATM switch which accommodates K dif- 
ferent kinds of source groups with corresponding K heterogeneous cell loss classes. 

We call a source which has cell loss class k, k 6 {1,2,..., K}, as class k source 
according to the stringency of the cell loss requirement. The number of class k 
sources is assumed to be Nk- We assume that the smaller the class number the 
higher the priority. That is, if K = the class 1,2, 3, 4, and 5 corresponds to the 
very stringent, stringent, moderate, loose, and very loose class, respectively. 

We put a Class Acceptance (CA) controller in front of the queue. The queue is 
finite with capacity B (cells), and the cell input and output operations are performed 
based on a time slot. A time slot is a time unit to serve a fixed length cell, and the 
time slots of different cell loss classes axe synchronized one another. 

The queue state is observed at the beginning of every time slot, and it is trans- 
ferred to the CA controller. The CA controller determines the number of classes 
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that can be allowed to input the cells into the queue based on the decision function. 
The decision function is called the Class Acceptance (CA) function, and it is denoted 
by y(x). 

The CA controller accepts cells from the sources whose classes are not greater 
than class y(n) when the queue occupancy at the beginning of that time slot is 
observed to be n, whereas the cells generated from the sources of classes greater 
than y(n) are discarded in that time slot. 

3 CLASS ACCEPTANCE FUNCTION 

We propose that y(x) can be determined by considering the following three condi- 
tions; 

• Extreme conditions : The CA function satisfies the extreme conditions 
y(0) = K and y{B) = 1. The condition y{0) = K indicates that, when the 
queue length at the beginning of the time slot is 0, the CA controller accepts 
cells from all the classes. The condition y(J5) = 1 indicates that, when the 
queue length is B, cells from only the highest class, viz., cells from the class 
1, can enter the queue. Note that y{B) = 1 holds because at least a cell can 
enter the queue if we assume the departure first rule in a queue. 

• Safeguard regions : The CA controller has to operate, to a degree, in favor 

of higher QoS classes, but it should also guarantee the best-effort QoSs to the 
lower QoS classes. To this end, the CA function should be generous to the 
lower classes when the queue occupancy is not too high, whereas it should be 
gradually and smoothly become stringent to the lower classes as the queue 
builds up. When the queue length approaches B, the control has to be very 
strict even to the higher classes. ^ 

In order to determine an optimal CA function which satisfies the required cell 
loss rate for each class, we investigate some heuristic decision functions. First, let us 
consider a uniform partition of a queue space. A typical curve for uniform partition 
is illustrated in Fig.l for AT = 5. In Fig.l, we also consider another partition, that 
is, a partition with safeguard. A quantitative comparison of two cases will be given 




Fig.l. Partition of a queue. 



in section 5. 

Let us put our objective to guaranteeing the cell loss requirement of the most 
stringent class. Let us determine the threshold for most stringent cell loss class 
based on the cell loss requirement of that class, which we cadi a hose threshold^ by 
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using the result of binary threshold for two-class system [8]. After that, we determine 
the remaining thresholds in a heuristic manner. This scheme is reasonable because 
we have to guarantee the most stringent class in the highest priority. 

First, let us determine the base threshold. It is known that the limiting queueing 
behavior of an ATM switch located arbitrarily in the middle of the network is 
accurately modeled by an M/D/1 type queueing model[8]. 

For the system with sources described by the mean arrival rate and CLR re- 
quired by it we can obtain the queue capacity which guarantees the CLR under the 
given cell arrival rate by using the result of M/D/1 type queueing model[8]. The 
queue capacity in this case corresponds to the base threshold in our discussion. That 
is, if we are given that the mean arrival rate of the most stringent class is Ai and 
the CLR of which is given by , then we can obtain the base threshold Th given by 

/n./.i-fa(l-A)(e^‘-l-2Ai/3) 

/n(e^ - 1 - 2A/3) - /n(e^i - 1 - 2Ai/3) ^ ’ 

where A is the total cell zurrival rate including the most stringent class. The remaining 
thresholds are determined by two heuristics described above. 

4 ANALYSIS AND QOS PERFORMANCE 

4.1 Queue analysis 

First, let us define the arrival process and the input process as follows. The arrival 
process is an aggregated source process which is generated from the superposition 
of K source classes, whereas the input process is a process which is composed of 
cells that pass through the CA controller. Thus, if we use the term ” arrival ” , it is 
related to the input side of CA controller, whereas the term input ” is related to 
the output side of the CA controller, which is the input to a queue. 

Let us assume that cell arrivals from sources of the same QoS class are indepen- 
dent and identically distributed (i.i.d.) with the cell arrival probability a^, A:G{1,2,. . ., 
K}. Let Ok be the number of cells generated from the class k source in an arbi- 
trary time slot, and let a<y(x) be the total number of cells that are allowed to enter 
the queue given that the queue occupancy at the beginning of that time slot is x. 
Note that the total number of cells that can enter a queue in an arbitrary time slot 
depends on the queue state at the beginning of that time slot. That is, if the CA 
controller find the queue length to be x, then the sources of only upper y(x) classes 
(i.e., sources of class 1,2,..., y{x)) is allowed to enter the queue in that time slot. 
Thus, a.jjy(a,) is given as follows. 

y(®) 

o<iy(®) = ]^afc- (2) 

k=i 



If we let 



y{x) 



0‘<y{x)(m) = Pr{o^(*) = m}, m=0, 1, . . . , ^ AT, 



(3) 
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be the probability of m cell inputs from an aggregate of sources of upper y{x) classes 
in a time slot, it is the probability that the total number of cells generated by the 
accepted sources is m given that the queue state is x at the beginning of that time 
slot. Let ajfe(m) be the probability that the number of cell arrivals from the source 
class k is m, 0<m<Nk> Then, we obtain 

“0^1 ^ 0!2 'A’ . . . ★ Oy (?7l) , 

where ★ denotes the convolution. The mean arrival rate of superposed arrival process 
is defined by where Xk is the mean arrival rate of the class A;, since we 

assumed the independency between different classes. The system stability condition 
states that A<k<L 

Let us consider an arbitrary time slot i, and note that a batch of cell inputs 
to a queue is fed from the higher y{xi) classes given that the queue state at the 
beginning of that time slot is x». A cell departs from the queue immediately after 
the beginning of a time slot if there is any cell in that queue. 

Let CL<y(xi) denotes the number of cells that enter the queue before the end of 
time slot i. The service rule is FIFO (First-In-First-Out) and the service order for 
the simultaneously entered cells is random. Thus, the input-output order seen from 
the queue is departure first. Then, we can obtain a formula for the queue length 
between the two consecutive time slots i and i-fl as follows : 



Xi\-\ — [(iCi IjO) -l-a<jy(a.^) j -^] ) 

where and indicates the minimum and maximum of r and cj, respec- 

tively. 

From the above discussion, we know that the sequence x = {x»; i >1} constitutes 
a homogeneous Markov chain [4] with the state transition probability defined by 

p(m, n) = Pr{xifi =n|x, = m},0 <m, n <B. (4) 

Since the source classes that are allowed to enter the queue is determined by the 
state of the queue at the beginning of that time slot, we can write the formula (4) 
as follows : 



p(m, n) = Pr{ [(xi - 1 , 0)+ + o„y , B] =n\xi = m}, 

which is rewritten by 



p(m,n) = Pr{[(m-l,0)++a<,j,(.„),B] =n}. (5) 

From (3), the formula (5) can be written as follows : 



p(m, n) = 



a<iy(o)(’^), 

m-h 1), 



m = 0 & 0<n<B — 1, 
m = 0 & n = B, 
m>0 & 0<n<J5 — 1, 
m>0 Sz n = B^ 



where the notation Z> indicates the number greater than or equal to Z. 

In order to represent the state transition probability in more explicit formula, 
let us recall that we assumed five cell loss classes; from class 1 to class 5, and 
correspondingly four thresholds, Ti, T2, T3, and T4, can be assumed. 
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First, we rewrite the state transition probability as follows : For m = 0, we have 



p(0, n) = 



{ 



Pn, 

Pb, 



0<n<J5-l, 
n = jB, 



where pn = Pr{a<,j,(o) = n} = a<5(n) and PB — Pr{a^j^>B} = \-Yl^pn. 
For we have 



p(m, n) = 



( 



Pn— n»fl ) 
P B—rTt^ > 
0, 



m — l<n<B — 1, 
n = B, 
otherwise, 



where pn-^i = Pr{a^y(rn) = n — m + 1} = a<,j,(„i)(n — m + l), and it is redefined as 
follows : 



Pn— n*+-l — \ 



Pn-rn^l j 
Qnr-mH , 
itH-1 > 

m|l j 
tn m 1 1 j 



l<m<Ti, 
7i+l<Tn<r2, 
T 2 H" 1 , 

T 3 -}■ 1 , 

74 + 1 ^ 771 ^ 5 , 



where pz = Pr{a<s = /} = cu<5(0» = Pr{a<4 = /} = a<4(/), n = Pr{a<3 = /} = a<j3(0» 

sz = Pr{a<2 = 0 = ^<2(0» tz = Pr{a<ji=/} = a<ji(/). 

On the other hand, Ps-rr^i = Pr{a<y(^)>5-mfl}, where PB-mfi = Pn, 

which can be rewritten in the saune way : 



Qs-rr^i, 7i + l<m<72, 

72 + l<rn<T3, 

73 + 1 <^< 74 , 

Ts-m+lj T4 + 1<771<5, 

where Pi = Pr{a <5 >/}, Qi = Pr{a<4 = Pr{a<3 >0» = Pr{a<i 2 

T/=Pr{a<]i >Z}. 

Then, we can obtain the state transition matrix of the queue, M= (p(m, ?i)), 
0<m,77<5, and if we let tTx be the probability that the queue length equals x in 
equilibrium and denote the stationary probability vector of the Markov chain by 
7T = (tto, 7Ti, . . . , 7Tb), then tt is the unique solution of the balance equation given by 



7rM = 7T, 7re = l, 



where the latter equation is the normalization condition and e is the (5 + l)xl 
column vector with all elements equal to one. 



4.2 Performance measures 

Rejection probability for class fc, where A; > 1, source is defined as a steady state 
probability that the class k source finds the queue occupancy in the range [TiC 4 -i-fc+ 
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1,B], fc > 1. Note that class 1 source is free from rejection. Thus, we obtain the 
rejection probability of class k source, Pr^ej^ fc>l, zis follows. 

B 

Pr^^j= ^ TTx, fc>l. 

On the other hand, the probability of no rejection, Pvnorej^ i e., the probability that 
all the classes can be accepted, is given by 

Ti 

P^norej ^ ^ ^ • 

®=0 

The cell loss in a queue results from two different reasons : The cell loss due to 
class rejection by CA controller and the cell loss due to buffer overflow after the cell 
has been allowed to enter the queue. The former corresponds to the rate of rejected 
(discarded) cells, whereas the latter corresponds to that of the overflowed ones. We 
consider these two cases in the following. 

Let Lr^cj be the cell loss rate of class A;, A:> 1, source due to class rejection, and 
call it a rejection loss rate. Then, we obtain a formula for the rejection loss rate for 
class fc, fc>l, as follows. 

^ B Nk 

^ ^ fc>l, 

^ a^/C+l-fc+1 ifc(®)=^ 

where Ai^. (x) is the probability that lk{x) cells of class k source arrive in a time slot 
given that the queue occupancy was x at the beginning of that time slot. 

Let be the cell loss rate of class fc. A; > 0, source due to buffer overflow, 

and call it an overflow loss rate. The cell loss of class k source due to buffer overflow 
depends on the total number of the aggregated inputs as well as the number of 
the vacant space in the queue at its input instant. If the queue length in that 
instant is x, x>0, and the total number of the aggregated cell inputs is Z(x), and if 
l{x)> B-x-\-lj then l{x)-B-{-x—l cells are lost due to buffer overflow. When x = 0 in 
that instant, the total number of the aggregated cell inputs is /(O), and if /(0)>B, 
then 1{0)—B cells are lost due to buffer overflow. We let ou(x) = /(x)~jB-hx— 1, x >0 
and ov{0) = l{0)—B in the sequel. We assume that among Z(x) cells the class k cells 
are /fc(x). Since the sources of each class are independent, the probability of cell 
loss for the class k source is that of the total cell loss probability. 

Since the aggregated cell arrivals from one class are independent of the aggre- 
gated cell arrivals from the remaining classes, the probability that /fc(x) cells arrive 
from a set of class k sources is given by Pr{ajb =ik{x)\ato£= l{x)} =Pr{aife =4fc(x)} = 
Aij^{x)j where ak is the number of cells arrived by source class k and atot stands for 
the number of cell arrivals from total accepted sources. 

Then, we obtain the formula for the cell overflow loss rate for a cell of class k, 
A;E{1, 2,3,4, 5}, source as follows. For class 1 cell, we obtain 

l(0)=BH /l(0H ^ 
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as=l ^(*>=S-a^f-2 ll(®H ^ 

T2 N^4 I ( \ 

^ 7t(*) ^ {or(xM((a;) XI 



l(®)=J3-®4'2 
T3 iV„3 



^i(®H 

Ni 



X £ {ot;(x)A(x) X 



x=T2+1 I(x)=;B-®+-2 

T4 AT<,2 



h(®H 

ATi 






B N^i 



il(x>=4 
Ni 






aj=£T44-l 



l(x)=J5-a>f2 



/l(x)=4 



where ^(0)>li(0),l(x)>li(x), A<jfc = ^^ A», iV<jfc = ^^ iVi and ^/(a;) is the proba- 
bility that a total of l{x) cells enter in a slot given that the queue occupancy was x 
at the beginning of that slot. Note in the above that N^i is identical to Ni. In the 
same manner, A<i is equivalent to Ai. 

For class 2 cell, we obtain 



iV<5 



N2 



Lrlf = ^A0) £ {ov(0)M0) X 



l{oy=BH 

N<5 



i2(o>=a 

N2 



Ti N^s N2 j / \ 

^7r(a:) ^ {ov{x)Aiix) ^ ‘^•^^ 2 ( 2 ^)} 



i(x)=;B-aH-2 

N 44 



i2(®M 

N2 



T 2 N^4 N 2 j f X 



as=£Ti+l /(x)=B-a+2 

T 3 N^3 



i^2 






as=Qr2-|4 l(x)=B-x+2 

T 4 N^2 



l2(*)=i 
iV2 



£ 5t(x) X {0V(®)-^|(®) X 



a?={r34-l l(x)=;B--a^f2 

where I{ 0 )>l 2 { 0 ) and l{x)>l 2 {x). 
For class 3 cell, we obtain 

iV<5 



^2(®)=i 



N 3 



= X {o^(0)M0) £ ^-^' 3 ( 0 )} 



i(0>=®fl 
iV<l5 



*3(0)=a 

i^3 



^3 I / \ 

-+y-£7r(x) X X 

^ x=4 i(x)=®-x4-2 l 3 (x)=i 
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1 1 ( \ 



x=tTi-H l(x)=B-<Di-2 

Tz N^3 



Nz 






A<3 

®=02+l l(®)=;B-^2 

where l{0)>h{Q) and l{x)>l 3 {x). 
For class 4 cell, we obtain 

N<5 



lz(x>=^ 



N4 






N 45 



l4(0)=l 

iV4 



A<5 



1 I f \ 



sc=l 

T2 



I (x )=J5— «H-2 

iV<,4 



iV4 



z: E E g 



A<4 

a5=JTi4-l l(x)=;B-a>f2 

where /(0)>^4(0) and l{x)>l 4 {x). 
For class 5 cell, we obtain 

N<5 



4(®M 



Ns 



= £ {ot'W^lKO) g 1^-4,, (0)} 

I(0)=a+-1 I5(0M ' 

1 I f \ 

3— E E {°^(3^)-4 iW g 



x=i l(x)=d5-aH-2 

where ^(0)>/5(0) and /(x)>^5(®). 



^5(*)=l 



5 NUMERICAL RESULTS 

Let us assume that the cell generating process follows a general independent burst 
process, and let it a binomial process b{Nk,(Tk), he{l, 2,. . . ,K}, For class k source, 
the probability of nik cell arrivals per time slot by class k sources is afe(mfc) = 
= cTifc) and the mean arrival rate is Xk = Nkak. Let /f = 5 as 
we assumed before, and the number of sources for each class is the same and Nk = 10 
for class A: = 1,2, 3,4 and 5. 

We assume that the queue capacity is small and it is given by B = 20. First, 
let us determine the base threshold. If we assume that the cell arrival rate of the 
most stringent class is Ai =0.1 and the required CLR for that class is assumed to be 
10“^^, and if we use the formula (1), the base threshold is obtained to be Tb = 14, 
which corresponds to Ti . 

Next, the decision function is shown in Fig.2, where the base threshold is 14 
and the other thresholds are given by appropriate proportions. These assumptions 
are effective throughout this section. Fig.3 illustrates the mean class rejection rate 
for classes 2, 3,4 and 5 as a function of the <72, the cell arrival probability of class 2 
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Fig.2. Partition with base threshold of 14. 



source. The relationships between ai,i = 1 , 2, 3, 4, 5 are given as follows: cri = <75 = 
0.010,(72 = (74 = [0.005,0.011] with an increment of unit 0.001, and (73 = (72 ♦ 1.5. 
This assumption holds throughout this section. Via preliminary computation we 
knew that the CLR of lO"*^^ for class 1 source can not be guaranteed if the mean 
arrival rate of the class 2 source exceeds 0.011. 

In Fig. 3 and its subsequent figures, the acronym UP and PS indicates the Uni- 
form Partition (UP) and Paurtition with Safeguard (PS) as we had defined in section 
3. Note that class 1 source is not rejected. We also find that the UP scheme ex- 




Fig.3. Mean class rejection rate. 



tremely discaurds the cells with low classes <x)mpared with the PS scheme. Thus, we 
cam conclude that the UP scheme over-regulates the cell ingress to a queue. 

Fig.4 illustrates the meam rejection loss rates for classes 2,3,4 and 5. The 
rejection loss results from the class rejection, which follows the same trend as that 
of Fig.3. This is easily expected. Fig.5 illustrates the meam overflow loss rate for 
classes 2,3,4 amd 5. As we can find from Fig.5, the overflow of cells under the 
UP scheme is much less tham that by PS scheme, which is self clear in that the 
UP scheme over regulates the cell ingression prior to the occurrence of the overflow 
compaured with the PS scheme. We cam find the overall cell loss rate from the last 
two figures. 
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Cell arrival probability of class 2 source 



Fig.4. Mean rejection loss rate. 




Cell arrival probability of class 2 source 



Fig.5. Mean overflow rate. 



6 CONCLUSION 

The main contributions of this paper are as follows : First, we proposed a cell access 
control scheme for guaranteeing multiple cell loss QoS in shared ATM output buffer 
by analytical model. Second, as an extension to the previous paper [6], we introduced 
the concept of the base threshold in a queue which plays a role of guaranteeing 
most stringent cell loss requirement exclusively from the remaining classes. This 
base threshold also acts as a marginal limit for guaranteeing no cell discard to 
all the classes, which would have an important implication. Finally, by numerical 
experiments we illustrated the effect of cell acceptance control in a queue to the QoS 
performance, from which we can estimate the maximum allowable cell input rate of 
associated QoS classes which guarantees the most stringent cell loss requirements in 
the system. Our future research area includes the modification of the CA function 
as well as the extension of the source model to a correlated one. 
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ABSTRACT 

In this paper, we evaluate the performance of a partial buffer system with finite capacity, 
deterministic service time and multiple sources. Each source is modeled by a Discrete 
Markovian Arrival Process (D-MAP). We evaluate the queueing system for several traffic 
composition and different sizes of the shared buffer area. Various traffic types are 
considered, including VBR (Variable Bit Rate) sources with periodical or negative 
exponential correlation functions and CBR (Constant Bit Rate) traffic with fixed interarrival 
cell emission. The probability distribution of the waiting time and the cell loss probability 
of each source are determined. 



Keywords 

D-MAP, Queueing System, Partial Buffer, Priority, Correlation Function, Cell Delay 
Variation, Cell Loss Probability, Waiting Time Distribution. 

1. Introduction 

In ATM networks, the AAL (ATM Adaption Layer) was standardized to adapt 
different kind of traffics to the cell transfer mode at the network edges. Former 
evaluations has shown that different traffic types also require acconunodated 
mechanism inside the network to garantee the individuel QoS parameters 
(Herrmann, 9/94). Due to the necessity of accomplishing these requirements, many 
mechanism are currently subjects of researchers studies. Because of its simplicity 
for implementation one of the most favourite candidate is the partial buffer 
mechanism. 

In this paper we use the D-MAP to imitate different types of sources. The D-MAP 
was introduced in (Blondia, 1989) and is the discrete-time version of the class of 
continous-time Markovian Arrival Process which was used in (Maglaris, 1988) for 
example. In our model we use the D-MAP for VBR-, CBR- and non-bursty-sources 
for different traffic composition. Each scenario consists of two priority and two 
non-priority sources to estimate the performance measurements. 
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The remainder of this paper is organized as follows. In section 2 we define the 
different types of sources considering in our model. The queueing model is 
specified and analyzed in section 3. In section 4, the numerical results are shown. 
Concluding remarks are given in section 5. 

2. Characterisation of the traffic sources 

Throughout this paper, each source is modeled by a D-MAP with m-phases. An 
arrival of a cell is presented by a type 1 transition between the m-phases of the D- 
MAP. In addition, there are also type 2 transitions, which don't cause arrivals. Both 
types of transitions are defined by (m x m)-matrices D and C, respectively. The 
elements Cy and dy represent the transition probability from phase i to phase j (i; j = 
0; 1; ;m-l). 

2.1 VBR traffic sources 

Besides traffic intensity, the most important parameter of VBR traffic is its 
burstiness behaviour. With (1) we are able to determine the autocorrelation 
coefficient of the number of arrivals. 



corr[A„,A„^f,] = 



7C D(C + 

A{1- A) 



( 1 ) 



For the derivation of equation (1) we refer to (Herrmann, 9/94). 

VBR traffic sources with periodical correlation function 

Equation (1) shows that corr [A„, A„+h] is only h-periodical, if the expression 71 D 
(C + D)** ' D e has this behaviour. To adhere the burstiness characteristic, the 
transition probability matrix (C + D) of the underlying Markov chain has to be 
periodical. As in (Herrmann, 8/94) the matrix of cyclic shifting was choosen. 



The resultant periodical correlation function is 



meD(C + D)"'De-(eDe)^ 



r A 1 iiic V,'-' ~ s — vs. ^ E/ 

con- [A „,A J = — — ^ 

me D e - (eD_e) 

VBR traffic sources with negative exponetial correlation function 



As in (Blondia, 1992) is shown, this behaviour can be modeled by a discrete-time birth- 
death Markov process, which is a special case of the D-MAP. The Markov process consists 
of (M+l)-phases i ( i = 0; 1; . . .;M) , which are related to the discrete levels of iA cells/s. 
During the sojourn times of a phase the cell rate is constant which results to fixed 
interarrival times betw^n phase transitions. 
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With reference to (Blondia, 1992) the parameter a, resp. p, is the probability that an active, 
resp. silent, on/off source becomes silent, resp. active, in the next time unit, d denotes the 
arrival time between consecutive cells of the same on/off source. The autocorrelation 
coefficient can be calculated with equation (3). 

corr[A „ ; (3) 

2.2 CBR traffic sources 

CBR traffic, which consists of a fixed emission sequence with the period T, can be 
modeled as D-MAP which underlying Markov chain (C+D) is periodical with T 
states. Thus for a CBR traffic source we can use the same Matrix of cyclic shifting 
which was already considered for VBR traffic sources with periodical correlation 
function. 

Due to the random delay in the customer equipment and in each multiplexing stage 
of an ATM network, the initally periodic cell stream is altered by introducing Cell 
Delay Variation (CDV). Following the CDV tolerance z is defined by the jitter cell 
stream Tcdv and the original constant time period T. 

T 

x = Tcdv-T (4) £[r] = aJ](l-a)‘-'0-7’) (5) 

1=1 

We consider the CDV effect in our model by using the matrix Dcdv = Diag 
(di;d 2 ; ;dt) ■ (C+D). For simplicity, let di = a for i = 1;....; T-1. 

2.3 Superposition of several traffic sources 

During a time slot several ATM cells can arrive at each output queue of an ATM 
node, due to the fact that cells of different inlets are destined to the same outlet. 
Therefore the resulting arrival process Q consists of the superposition of n D- 
MAPs. When we use the properties at the Kronecker product as demonstrated in 
(Graham, 1981) the transition probability matrix Q can be decomposed. 

Q = Do + Dj + D 2 + • • • • + D„ , whereby 

Do = ® C^^^ ® C^^* ® • • • •€) C^"’ 

D| = D^‘‘ 0 C® 0 C‘^^ 0 ■ • • -0 C^"'‘> 0 C‘”’ + C“^ 0 D‘^^ 0 C<^> 0 

.0C("-»0C<">+. • • + C''^0C®0C®0 • 0 D'"'*' 0 C^"^ + 

C(i) (g) ® C^^' 0 • ■ • ■ 0 C‘"'‘’ 0 D*"’ 



D„ = D*'^ 0 D® 0 D^^* 0 • • 0D‘"* 



( 6 ) 
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3. Queueing Model with Partial Buffer Sharing 

The partial buffer sharing mechanism, which we are considered in our queueing 
model, was proposed in (Blondia, 1989, Maglaris, 1988). The traffc model, which 
is considered in this paper, is shown in Figure 1. 




Figure. 1 Partial buffer sharing mechanism 



The buffer is partitioned by the threshold T in two areas. The lower section of the 
buffer, which is called shared area, accepts arriving cells of each class (i.e. priority 
and non-priority cells). On the contrary the buffer area above the threshold T can 
only be entered by cells with semantic priority. Therefore arriving non-priority cells 
will loss, when they observe a buffer occupany equal or greater than T. The whole 
system consists of N buffer spaces and additionally one space, which is provided by 
the server. 



In this paper the service time h(t) of a cell is assumed to be constant and is equal to 
a time unit. The service discipline is FIFO. The transmission rate for each incoming 
linie i (i = 1,...,4) is equal to those of the outlet. Throughout this paper the arrival 
processes 1 and 2 represent non-priority cell streams, whereas the arrival processes 
3 and 4 consist of priority cells (denoted by the index n and p in Figure 1, 
respectively). In case of a batch arrival the sequence of cell admission is random, 
i.e. we do not consider any enqueueing sequence priority in our model. 

3.1 The embedded Markov Renewal Process at Departure instants 



Next to we consider the occupancy of the system at departure instants Xi (i = 0, 1, 
2,...). We assume that departures and arrivals occur at the end of a time slot. 
Further an arriving cell should enter the system before the served cell leave the 
system (Arrival First). The resultant semi-Markov kernel q(t) is shown in Figure 2. 
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Figure 2 Semi-Markov kernel of the system with partial buffer sharing 
(N+1 rows and N+1 columns, T=8) 



The elements of the submatrices are defined as follows: 

j^A^(t)j : The joint probability that a departing cell leaves a non-empty system 

and during the time-interval t there are k arrivals. The indices i and j denote the 
phases of the arrival process at the beginning and the end of the time-interval, 
respectively. The index b refers to the relevant buffer area at which 's' and 'p' 
denote that the transition occurs inside the shared area or inside the priority area, 
respectively. The index 'sp' denotes that a transition happens from the shared area 
into the priority area. 



: eqivalent defined as^A^(t)j but with the difference, that a departing 
cell leaves an empty system. 



It is assumed, that the transitions ^B^(t)j only occur inside the shared buffer area, 
i.e. threshold T > 7. By that can be computed as follow: 

V 

(0 = X ; M = max[l;k-3]; v = min[4;k+l]; 0< k S7 (7) 

fl)= p 



whereby Do, D„, are defined as in (6) with n = 4. The calculation of matrices 
(t) depends on the affected buffer areas. Transitions inside the shared buffer 
area without cell loss; 



a;=d, 



;i = 0; 1;2;3;4 



( 8 ) 
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With reference to section 2.3 D| is the superposition of D-MAPs, here n = 4. 

The transition probabilities from the shared area into the priority area depend on 
the system state Xni 



Xn = T- 2 : 



Af =A^+~AJ 



( 9 ) Af=^Aj 



( 10 ) 



Xn = T-l: 



Af = A' + ^ • [d^‘^ ® ® ® C^'‘^ + ®D® ® ] ■ 



■f[< 



+^.|C^‘> (g)D® 0D® ®D^'*^ +D^'^ ® C®®D® 



].1a: 



( 11 ) 



Af=A^+~Aj (12) Af=i-A5 

2 O 



( 13 ) 



Xn = T: 



Af'’ = Af +D<*> ® ®D<^> ® + 

+ D^‘^® ® ®D‘“^]+y [c^‘^ 0 D® ®D<^‘ ® +C^'^ 0 

® D® 0 0 0 D® 0D<^^ 0 C‘‘‘*]+ 

+ 1.|^D^‘>® 0 ®D‘‘*’] 



( 14 ) 



®C® ® C® +C^'^ ®D® ® 

®D^'‘^]+|-[d^'^ ®D® ®D® ®C^'*^]+-|[d<*^ ® D® ®d^^ ® 

®D^'‘^ +D^'^ ®C® ®D^^^ ®D^'‘^ +C^'^ ®D^^> ®D® ®D^'‘n+--Ai 

J 6 ^ 
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Af +C^'^ (16) 

In the equations (9) - (16) the factors are based on the theory of combination and 
represent the ratio of valid cell arrival sequences to all possible cell arrival 
sequences for the considered event. 

Transitions inside the priority area: 

A^= (17) 

Af = (C^’^ +D^'^)® (C® +D®)®D^^^ + (C^*^ +D^'^)® 

®(C® +D®)®C® 

Af = (C^'^ +D^'^)® (C® +D®)®D^^^ 

The transition probability matrix of the underlying Markov chain is obtained by 
consideration of the marginal values. Since the service time is identical with the 
time unit, Aj(t) in equations (8) - (19) are directly the marginal values. For the 
marginal values of B^(t) we obtain: 

V 

= (I - Do)'* "y^Da)Pk-a>+l M = max[l;k-3];v = min[4;k+l];0<k<7 (20) 

(0=^p 



(18) 

(19) 



3.2 The stationary queue length distribution 

For the computation of the stationary vector x , which denotes the number of cells 
and the phases of the arrival process after a departure instant, we follow the 
procedure is used in (Herrmann, 9/94). The vector x can be partitioned as x_= ( 5 ^, 

..., Xn)» whereby 2 ^ (k = 0,...,N) is a vector with components x^j (i = 0; ; mi x m 2 

X m 3 X ni 4 ) being the probability that a departing cell leaves k cells in the system 
and i is the phases of the whole arrival process at the departure instants. The vector 
X satisfy the equations (21). 

xq = x ;xe=l (21) 

To computate the waiting times and the loss probabilities of each arrival process, 
we need the system occupancy ^ at arbitrary time instants: 

yo=;^5o(I-Do)-' (22) y^=^[xo(I-Do)'*D,+x.] (23) 

; for 1 <r < 4 

1 

y =— X, ;for5^<N (24) £* = Xq (I - Dq)'* e + 1 
'' E 



( 25 ) 
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3.3 The Ceil loss probabilities 

The cell loss probabilitiy is defined by the ratio of the number of lost cells to the 
number of arriving cells in all. Following denotes the cell loss probability of 
the arrival process i. 

On principle an arriving non-priority cell, which observed a system occupancy, 
i.e.buffer occupancy including the one in service, equal or greater than the 
threshold T+l is lost. Equivalent an arriving priority cell is lost, when the queue is 
wholly occupied at the arrival instant. 

By noting that is the probability that a batch of n cells arrives which 

includes cells of the streams i and k the loss probabilities can be calculated with the 
equations (26) - (27). 



p(i) 

loss 




2 13 

y,..! DS’ e + - J d!,“ e +- ^ D|,''e + - y^ DS' e + 

yT.D!;'e+-i y D!|' e + I y E(i) } / tc • E(i) e 



(51) 



i = 1; 2 with E(l) =D^‘^ ® +D^“^) and 

= {1 y } /7C-E(i)e (53) 

loss 2 ■”* N L J 



i = 3;4with E(3) = (d‘^+D<’^)® (C® +D® +D^'‘>) and 

E(4) = (C® +D®)®(C® 



3.4 The waiting time distributions 

On condition that an arriving cell is not lost, the waiting time of a cell depends on 
the buffer occupancy at arrival instant and in case of a batch arrival additionally on 
the allocated position in the buffer. In general, the waiting time can only take on 
values, which are multiple of the service time h(t)=l. An arriving cell gets 
immediately service, when the system occupancy is zero or one at the arrival 
instant, due to the fact, that in a busy system the serviced cell leaving the system at 
that moment. For each arrival process we obtain the following expressions: 
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P{W =/^} = { y^,,) Di‘'e +1 (y^+ e (l^., Vo + 

+ + s (i^-2-V.+ y^-.Vo+ y;..,)- 

• WD4 e } / ^{Wi =//} ; 0 < //< M; i = 1, ... 4 

/i=0 

M = Tfori= l;2anM = Nfori = 3;4 (28) 



In equations (28) the operator is only equal to lif x is true, 0 otherwise. 

4. Numerical Results 

In this section, we present numerical examples for various scenarios. The 
parameters N and h(t) of the queueing system, which was introduced in section 3, 
are constant in all scenarios. 
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Figure 6 Waiting time distribution of 
Arrival process Ei 



Figure 7 Comparison of cell loss 
probabilities scenario 2 and 6 



We choose N = 30 (cells) and h(t) = 1, i.e. the service time is equal to a time slot. 
The types of arrival processes we consider throughout this section are shown in 
Table. 1. In column 1 of this table, the different types are denoted by capital letters, 
at which the indices 1 and 2 mark processes with a mean arrival rate of X. = 0.2 or X 
= 0.25, respectively. In Table 2, the various scenarios which we consider in our 
investigation are shown. The comparison of the first four scenarios discloses the 
influence of the correlation function in the arrival process No.2 on the QoS- 
parameters. The results are demonstrated in Figure 5 and Figure 6. 



From the curves, we can derive that the cell loss probabilities and the waiting time 
distributions of the streams are essentially dependent on the correlation function in 
the arrival process No.2. With the negative exponential correlation function, the 
QoS parameters attain the adverse values. The sensitiveness of the QoS parameters 
from the correlation function is smaller when the threshold T is low. The results 
also show that threshold levels close by thewhole buffer capacity of the system are 
not a good policy, because the effect of the partial buffer mechanism can be 
compensated by the correlation function. 
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Figure 5 Cell loss probability of 
priorty and non-priority streams 



Figure 8 Comparison of the waiting time 
distribution scenario 2 and 6 



To evaluate the influence of the offered load for the QoS parameters, we compare 
the numerical results of scenario 2 with those of scenario 6. We consider a total 
offered load of p = 0.8 or p = 1.0, respectively. Figure 7 and Figure 8 show that 
the cell loss probabilities and the waiting time distributions are strongly dependent 
on the total load. In the saturated case, only the cell loss probabilities of the priority 
cells can be sufficiently influenced on the threshold T. As we consider that the 
variation of the waiting time w influences the CDV on the large scale, the 
threshold T is also useful to control the CDV of time-sensitive cells, e.g. CBR 
traffic. In scenario 6 we obtain var[w] = 72,7 for T = 30 and var[w] = 18,9 for T = 
15. 

5. Conclusions 

We demonstrated that the presented model of the D-MAP/D/1 queue with partial 
buffer mechanism allows a comprehensive analysis, including for heterogenous 
scenarios. The D-MAP allows to imitate different types of traffic sources. The cell 
loss probabilities and the waiting time distributions were investigated for each 
source. The numerical results disclosed the influence of the correlation functions 
in the arrival processes to the QoS paramters. It was shown that the partial buffer 
mechanism is able to minimize this influence when the difference between the QoS 
requirements is great, i.e. for small threshold levels. 
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Abstract 

In order to guarantee quality of service, we must be able to calculate the link 
capacity, i.e., the total number of calls of different types that can be admitted 
on a single link at any given time. In this paper we use the schedulable region 
to represent the link capacity, and, we present a new approach for computing 
the schedulable region. Our methodology relies on real-time quality of service 
measurements to dynamically compute the size and shape of the schedulable 
region. We do not make any assumptions on traffic source models or scheduler 
operations. 



Keywords 

Quality of Service estimation. Multimedia Networks 



1 INTRODUCTION 

Guaranteeing Quality of Service (QoS) is the main challenge in future broad- 
band networks. When several calls are statistically multiplexed into a single 
channel, there is the need to find out if and how the telecommunication sys- 
tem can guarantee their QoS constraints. In other words the problem is how 
many calls of a given type can be admitted to the link at any given time. 
In this paper we focus on the so-called “low-level” QoS and in particular on 
the cell flow level of an ATM network. At this level, the quantities of interest 
are the probability of exceeding a given value of delay and the probability of 
having cells blocked due to the lack of transmission resources. 

Each node of a telecommunication network has a finite switching capacity, 
due to the finite processing power and the finite link capacity. This switching 
capacity strongly depends on traffic statistics and QoS constraints. In a circuit 
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switching, this maximum switching capacity is easy to find, while in a packet 
switched framework in which a set of QoS have to be guaranteed, the switching 
capacity is, in general, unknown and the problem is to find it. 

The problem of finding the link capacity has been largely considered and 
many examples can be found in the literature (see for example (D. Ferrari 
et ai 1990, R. Guerin et al. 1991)). All these techniques rely on very strong 
assumptions on the system structure (e.g., markovian behavior of input flow, 
FIFO scheduling, simple server model), and they generally need a computa- 
tional effort that might lead to a non effective utilization in a real-time frame- 
work. A common problem with these techniques is that the analysis generally 
focuses only on the entry points of the network since source models are usu- 
ally non effective as the flow goes deeply into the network. This is mainly due 
to the fact that each scheduler might change the flow properties that cells 
had when they entered the network (J.F. Kurose 1993). Several techniques 
have been proposed to overcome this problem (see for example (A. Parekh et 
al. 1992)). Other techniques keep track of the variations that the single flows 
have as they travel along the network (J.F. Kurose 1992). They do not try to 
preserve the characteristics of the flow, but instead they are able to compute 
bounds on a node-by-node fashion. 

The approach which we are considering in this paper is to find the link 
capacity of a node without relying on any mathematical model of sources or 
on the presence of a given scheduler, but only by means of measurements on 
the QoS. It is worth to point out that by means of measurements it is not 
possible, in general, to find the real switch capacity but only an estimation 
of it. On the other hand, this approach, has the notable advantage of being 
applicable to a wide range of situations, since it does not require any particular 
constraint on the switch components such as the scheduling policy, the buffer 
size or the buffer management policy. In (J. M. Hyman et al. 1991), given a set 
of traffic classes, the switch capacity is estimated by means of a simulation 
process and described by a data-structure called “schedulable region”. The 
main problem with this approach is that, if the traffic statistics of a given class 
change, the switch capacity previously found is no longer reliable. Another 
simulation therefore would have to be run with the new traffic characteristics. 
This problem could be solved if we were able to estimate the link capacity in 
real time. In this paper we analyze this problem, suggesting a framework in 
which this complex estimation task can be carried out. 

In Section 2 we introduce the framework and the model of the switching 
system we will consider. In Section 3 we describe the estimation approach 
we propose, while in Section 4 we present some numerical results. Section 5 
draws the conclusions of this work. 
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Figure 1 An example of schedulable region. 



2 A FRAMEWORK FOR LINK CAPACITY ESTIMATION 

In this paper we represent the link capacity using the schedulable region. The 
schedulable region of a system is the set of call configurations, for the various 
traffic classes, for which QoS would be guaranteed. In Figure 1 is depicted 
an example of schedulable region of a link over which three traffic classes are 
multiplexed. Over that link, if no calls of class I and III are present, than 
more than 4000 class II calls can be multiplexed, and all of them will have 
their QoS guaranteed. 

The link capacity is a function of a number of parameters such as the link 
speed, the scheduling policy, the buffer policy, the traffic statistics and the 
buffer size, and therefore it changes as a result of changes in one of them. The 
problem we will analyze in this paper is to keep track of these variations in 
real time in order to maintain consistency on the network. It helps to think 
of a system that once in steady state is perturbed. There are no general rules 
that enable to compute the new boundary of the schedulable region given that 
some parameters have changed. 

In order to keep track of the schedulable region in real time is therefore 
necessary to exploit estimation tasks. Estimating the schedulable region means 
to estimate what is the maximum load achievable by the multiplexer, and 
this, in turn, means to understand how QoS changes as the number of calls 
increases. The system therefore has to perform two estimation tasks. The first 
is the estimation of the current level of QoS which is being offered to the calls 
in progress. The second task is the estimation of the maximum number of calls 
that could be accepted by still guaranteeing QoS constraints. In this paper 
we will focus on the second estimation task. 



2.1 The system model 

The key point of the underlying switch model is the presence of a multiplexer 
that is designed to work with a finite set of traffic classes. The traffic class is an 
attribute that reflects the quality of service parameters and that it is defined 
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by a set of quality of service constraints. For the sake of simplicity, we restrict 
our analysis to a link shared by two different classes of real-time traffic: voice 
and video. In such a framework, QoS are given in terms of maximum cell 
delay and maximum probability of exceeding such delay boundary. We will 
refer to the maximum delay for class /i as 5^ and to the maximum probability 
of exceeding (i.e., the QoS constraint for class h), as Hence, for class 
h, QoS will be guaranteed if: 

Prob[celldelay > S^] < (1) 

We will moreover express the load in terms of number of calls for the various 
traffic classes multiplexed in the system. We will refer to the number of calls 
for class has K^. We will study two different scheduling disciplines: FIFO and 
SPS. Moreover, we will focus on delays therefore assuming infinite buffer size. 
The server models an ATM link which transmits cells at a constant rate of ^ 
bits/sec. The scheleton of the model of such a multiplexing system is depicted 
in Fig. 2. In all the experiments we will show in the remainder of the paper, 
the link speed is equal to 100 Mbits/sec. The voice source is generated with 

K* video caUi 



K** voice calls 




Figure 2 The model the multiplexing system. 

the well-known On-Off model with exponential state transition rates. When 
in Off state, the source is idle, while when in On state the transmission takes 
place at a rate of 64 Kbit /sec. The On and Off average periods are respectively 
0.352 sec and 0.653 sec. The generated flow is supposed to be inserted in the 
payload field of ATM cells. The video source generates 24 frames per second 
and each of them is associated a variable number of bit. The number of bit 
per frame is a random variable i/ that comes from a given distribution and 
that has a correlation given by a particular extraction rule. Such video stream 
is generated by using the TES (Transform, Expand, Sample) technique (A. A. 
Lazar et ai 1994). We considered three different video sources, which in turn 
correspond to three different distributions for the variable i/. Let us call them 
Videol, Video2 and Video3. Figure 3 show the three distributions for the three 
different video sources. In particular, Videol and Video2 have a peak rate 
equal to 56000 bits/frame, while Video3 has a peak rate of 64000 bits/frame. 
It is worth noting that for Videol, the probability of exceeding 50000 bits/sec 
is extremely low. As regards average rates, Videol and Video2 have an average 
rate of about 23000 bits/frame while Video3 has an average rate of about 
44000 bits/frame. Notice that actual video sources might have higher peak 




Real-time estimation of link capacity 



105 



0.14 
0.12 
0.10 
0.08 

P[bit/frame] 

0.06 
0.04 
0.02 
0.00 

0 10000 20000 30000 40000 50000 60000 70000 

bit/frame 




Figure 3 The distributions for the three video sources 

rates. We adopted these figures in order to test in a more reliable way the 
effect of statistical multiplexing. 



3 A NEW APPROACH: MODELING DELAY DYNAMICS 

The approach we are considering in this work is to directly focus on delay 
distributions, trying to analyze their dynamics. We want to find a parametric 
model for delay distributions and to study how the model parameters change 
with variations both in the load and in traffic statistics of the input streams. 



3.1 The delay distribution model 

The model we suggest in this paper describes delay distribution for the traffic 
class h as a collection of N exponential functions, each of them representing a 
portion of the delay axis. More in particular, if pdf^ (x) is the delay probability 
distribution for Class /i, then the model can be expressed in the following way: 

pdf*(x) = (2) 

i=l 

Figure 4(a) gives a pictorial representation of the model expressed in equa- 
tion (2), while in Figure 4(b) is shown an example of an actual delay dis- 
tribution which comes from an experiment with = 80, = 1980, and 

SPS scheduler. The shape of this delay distribution is clearly represented by 
the model (2). The two lines represent the exponential functions (in this case 
two) that approximate the delay distribution. We have observed the same 
behavior of the pdf for various traffic load characteristics as we will present 
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later in Section 3.2. In our case, the schedulable region is defined by the set of 





ceDdelqr 
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Figure 4 The model for the delay distribution, (a) Pictorial representation; 
(b) Example of delay distribution for Class II traffic. 



pairs such that the delay constraints for all the traffic classes are 
guaranteed. With respect to our delay distribution model (see equation (2)), 
this turns into the following: 



roo 

/. 5 : 

1=1 









( 3 ) 



Equation (3) has to be satisfied for each traffic class A (A = /, //). To find 
the boundary of the schedulable region we first fix the value of and find 
the maximum value of that satisfies (3) for A = I, II. We then do the same 
operation, fixing ^ to find the maximum value for . 



3.2 Delay distribution dynamics 

In Section 3.1 delay distributions have been modeled as a collection of ex- 
ponential functions. We have now to investigate how all these functions are 
affected by a change in the load. In other words, we have to find a model 
for the parameters of the exponential functions able to give us an insight on 
how they depend on the load. We have then to exploit such a model in order 
to estimate the boundary of the schedulable region. More specifically, notice 
that the parameters and 6^, in equation (3) are function of the load (i.e.. 
Since our goal is to predict the boundary of the schedulable region 
before actually reaching it, we have to determine how af and change when 
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the load is increased. It is worth to point out that also xf and depend on 
the load even if, from our experiments, we noticed that the effect of varying 
the load is small as regards them. Let us concentrate, for the time being, on 
the parameters and : in our first experiment, we load the system with 
the traffic classes described in Section 2.1, with SPS scheduler. Figure 5(a) 
shows how the pdf of Class II changes as the load increases. Fig 5(b) the 
approximation of equation (2) for the same experiment. Labels “1”, “2” and 
“3” both in Figures 5(a) and 5(b) refer respectively to (iiT^, = (80,1980), 
{K^ , = (80,1960) and (Fi^, = (80,1940); the scheduling policy is 

SPS. Let us assume, for this experiment, that the pdf, for h = II, is composed 





delay 



(a) 
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Figure 5 Delay distributions with increasing load (a) Actual distributions; 
(b) Model 



of two exponential functions, that is: 



pdf^^(ar) = + e“a 



( 4 ) 



Figures 6(a,b,c,d) show how the parameters a(^, and change as 

the load is increased. The hypothesis that we make is that, in the range of 
load investigated, the behavior of the model parameters is linear, with respect 
to the load. More specifically: 



This is an heuristic assumption that comes out from a number of experi- 
ments we carried out. The problem turns now into finding the values of ri^h, 
i want to find them by only utilizing measurements, we 
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(C) (d) 



Figure 6 Parameters a and 6 as a function of the load. Scheduler=SPS, 
= 80, /^ = 100 Mbits/s. (a) (b) b{^; (c) (d) 



have to perform a fitting operation among the measured values of a* (to find 
r)^h and i/^h) and b^ (to find rjf,h and whenever a new load condition 
occurs, a new fitting task is performed and rj^h , i/^h , and i/f,h are properly 
adjusted. Figure 7 shows this task for different values ot the load. Notice that. 
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Figure 7 The model for the delay distribution, (a) Various fitting phases for 
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in this example, has been assumed to be zero. Each time we add calls to 
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the system (i.e., in this Ccise as increases), we can collect new information 
that adjust our estimation. By utilizing the various approximation obtained 
with different values of , and by means of both (4) and (3), we are able 
to estimate the schedulable region. 



4 EXPERIMENTAL RESULTS 

In this Section we report and discuss some numerical results on specific ex- 
amples. More in particular we show how the estimating mechanism is able 
to refine its estimation as the load increases. We use the system described in 
Section 2.1 in which two traffic classes are statistically multiplexed over a link. 
For the sake of simplicity we only consider variations of one traffic class keep- 
ing the other one fixed. More specifically, we keep Class I traffic fixed to 80 
calls (i.e., = 80) and we vary the number of Class II calls. Each time Class 

II load increases, we perform the mechanism described in Section 3 in order to 
update the estimation of the schedulable region. As the system acquires more 
information (i.e., the load increases) it refines the estimation of the boundary 
of the schedulable region. We expect, therefore, to obtain rough estimations 
when the load is low (i.e., deep inside the schedulable region) which turn into 
better ones as the load increases. Class I and II load is represented by video 
and voice calls, respectively, modeled cis described in Section 2.1. The three 
different types of video sources described in Section 2.1 are considered. Both 
FIFO and Static Priority (SPS) schedulers have been taken into account. We 
always consider to have an infinite buffer. As regards QoS, both video and 
voice cells are dropped when they experience a delay greater than 2 ms., and 
QoS are guaranteed when the dropping probability does not exceed 0.005 for 
video and 0.05 for voice (i.e., = 0.005, = 0.05). In order to be able to 

test the efficiency of the estimation mechanism, we computed beforehand the 
“real” schedulable region with an exhaustive method and very long simula- 
tions. 

Figure 8 shows the results of the estimating mechanism, when SPS scheduler 
is adopted (the horizontal line in the plot represents the “real” schedulable 
region) . Class II load has been increased from a point well below the schedu- 
lable region to the point on the boundary of the schedulable region. Notice 
that the range of the X axis of the three cases is different: this is because 
different traffic statistics (i.e., Videol, Video2, and Video3) lead to different 
schedulable regions. 

We observe that when Class II load is small, our approach underestimates 
the boundary of the schedulable region. As the Class II load increases (i.e., as 
the load approaches the schedulable region boundaries) the estimation suc- 
ceeds in correctly predicting the boundary of the schedulable region. It is 
worth noticing that, as regards QoS measurements, in this experiment we 
only measured Class II delay: SPS scheduler, in fact, always gives priority 
to Class I cells which, therefore, never experience delay. This means that, in 




110 



Part Two Traffic Management 



estimating the boundary of the schedulable region, we exploit (3) for h = 2 
only (i.e., for Class I QoS are always guaranteed). 
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Figure 8 The schedulable region estimation (SPS scheduler), (a) Videol; (b) 
Video2; (c) Video3. 
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Let us turn now to the FIFO scheduler. In this case we not only have to 
consider Class II delay but also Class I one. In fact, the FIFO discipline does 
not make any difference between the various traffic classes involved in the 
multiplexing system, and therefore the schedulable region boundary is found 
when QoS of any one of them is not guaranteed anymore. Figure 9 shows the 
results of the estimating mechanism for the two traffic classes (i.e., V’ for 
Class I and for Class II). Notice that the lowest one of the two estimations 
has to be considered as ‘‘the” estimation of the boundary of the schedulable 
region. 



5 CONCLUSIONS 

A framework for a real time estimation of the link capacity in a multiclass 
network has been presented. A model able to capture delay distribution dy- 
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Figure 9 The model for the delay distribution (FIFO scheduler), (a) Videol; 
(b) Video2; (c) Video3. 



namics has been analyzed and exploited for the estimation task, and numerical 
results from a number of experiments have been presented. 
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Abstract 

Quality-of-Service (QoS) routing tries to select a path that satisfies a set of 
QoS constraints, while also achieving overall network resource efficiency. We 
present initial results on QoS path selection for traffic requiring bandwidth 
and delay guarantees. For traffic with bandwidth guarantees, we found that 
several routing algorithms that favor paths with fewer hops perform well. For 
traffic with delay guarantees, we show that for a broad class of WFQ-like 
scheduling algorithms, the problem of finding a path satisfying bandwidth, 
delay, delay-jitter, and/or buffer space constraints while at the same time 
deriving the bandwidth that has to be reserved to meet these constraints, is 
solvable by a modified version of the Bellman-Ford shortest-path algorithm 
in polynomial time. 



Keywords 

Routing, quality of service, integrated services networks 



1 INTRODUCTION 

Future integrated-service packet-switching networks (ISPN) will support a va- 
riety of service classes to meet diverse quality-of-service (QoS) requirements 
of existing and emerging data and multimedia applications. Among the ser- 
vice models being proposed, two classes are of particular interest: traffic with 
bandwidth guarantees and traffic with stringent end-to-end delay bounds. 
The former includes the controlled- load (IETF) and available-bit-rate with 
minimal cell rate (ATM Forum) services. The latter includes the guaranteed 
service (IETF) and the constant- and variable-bit-rate services (ATM Forum). 

QoS routing is the first step toward achieving end-to-end QoS guarantees. 
It identifies paths that meet QoS constraints, and selects one that leads to 
high overall resource efficiency. In this paper, we present initial results on 
routing traffic with bandwidth guarantees (Section 2) and latency guarantees 
(Section 3). We summarize in Section 5. 
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Figure 1 Topologies 



2 BANDWIDTH GUARANTEES 

For services with bandwidth guarantees, QoS routing tries to identify a feasible 
path, i.e. a path on which all links have an unserved bandwidth that is higher 
than the requested bandwidth. Several path selection algorithms have been 
proposed (see Section 4), but a systematic evaluation of algorithms is missing. 
In this section we present initial results of a simulation study comparing the 
following four algorithms: 

• Widest-shortest path: a feasible path with the minimum hop count. 
If there are several such paths, the one with the maximum bandwidth is 
selected. If several such paths exist, one is randomly selected. 

• Shortest- widest path: a feasible path with the maximum bandwidth. 
If there are several such paths, the one with the minimum hop count is 
selected. If several such paths exist, one is randomly selected. 

• Dynamic-alternative path: a widest minimal-hop path. If no feasible 
minimal hop path exists, find the widest path that is one hop longer. If 
several such paths exist, one is randomly selected. Reject the request oth- 
erwise. 

• Shortest-dist(P, 1): a path with the shortest distance 

^ 1 

Shortest— dist(P, 1) = ^ — 

where Ri, - ,Rk are the bandwidths available on the links on path P, 
This algorithm has been shown to be effective when selecting routes for 
high-bandwidth connections (Ma et.al, 1996). 

Our study uses two topologies (Figure 1). The traffic load is a combina- 
tion of audio and video sessions. We assume that the requested bandwidth is 
uniformly distributed between 16 ^ 64 kilobits/second for an audio session. 
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(a) MCI: 60%/40% Audio/Video 




(b) Clustered: All Video 



Figure 2 Blocking rate as a function of an evenly distributed network load 




Figure 3 Call blocking rate as a function of network load: MCI topology, 
100% Video traffic, Unevenly distributed load 



and between 1^5 megabits/second for a video session. Sessions have a Pois- 
son arrival rate. Based on Bolotin (1994), we use a lognormal long-tail call 
holding time distribution. All four algorithms use the dynamic link state in- 
formation (residual bandwidth) with a refresh rate of 30 seconds. A common 
performance metric for traffic with bandwidth guarantees metric is the Call 
Blocking Rate, the percentage of session requests that is rejected. This metric 
is however misleading if sessions can request different amounts of bandwidth. 
Thus, we introduce a new metric, the Bandwidth Blocking Rate, which takes 
the session bandwidth into account: 

bandwidth blocking rate = g ieg bandwidth(») 

Ei65 bandwidth(i) 

where B is the set of blocked sessions and S the set of requested sessions. 
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Figure 2 shows the bandwidth blocking rate as a function of network load 
for the case that the traffic is evenly distributed. Figure 3 shows the result for 
an uneven load, where most of the traffic is between the East and West Coast. 
In all cases, we observe that most algorithms achieve similar performance. The 
exception is the shortest- widest algorithm, which tends to pick longer path, 
and is therefore more resource intensive. 

This result is different from that obtained for best effort traffic by Ma et.al. 
(1996), where the shortest distance path gave overall the best performance. 
The difference is that with best effort traffic, all paths are feasible, even paths 
that are heavily congested relative to other parts of the network. The shortest 
distance algorithm was able to route around congested links more effectively 
than, for example, the widest-shortest path. However, when bandwidth is 
reserved, heavily congested links will no longer be feasible, so any algorithm 
will route around them, and algorithms that favor short paths will give similar 
performance and have efficient resource utilization. 



3 DELAY GUARANTEES 

QoS constraints for traffic requiring delay guarantees include end-to-end de- 
lay, delay-jitter, and buffer space bounds. Most existing QoS routing studies 
assume these QoS constraints are independent, and a well-known result is 
that finding a path with (independent) bandwidth, delay, and delay-jitter 
constraints is NP-complete (Wang and Crowcroft, 1996; Garey and Johnson, 
1979). In practice these bounds are functions of the reserved bandwidth, the 
selected path, the traffic characteristics, and the switch scheduling algorithm, 
and they are not independent. We show that the problem of finding a path 
satisfying bandwidth, delay, delay-jitter, and buffer space constraints can be 
simplified by taking these relationships into consideration, 

Recent studies in defining scheduling disciplines to support end-to-end de- 
lay guarantees have identified a class of rate-proportional scheduling algo- 
rithms (Zhang, 1995 and its references), including Virtual Clock, Weighted 
Fair Queueing, Worst-case Weighted Fair Queueing, and Self Clocked Fair 
Queueing. These WFQ-like scheduling algorithms isolate each guaranteed ses- 
sion from other sessions to ensure a guaranteed share of link resources. The 
queueing delay of the session is thus determined by the bandwidth being re- 
served and the burstiness of the traffic source. In this section, we show that 
in networks that use these WFQ-like scheduling algorithms, finding a path 
that satisfies delay, delay-jitter, and buffer space constraints is solvable in 
polynomial time if we take into consideration the relationship between the 
bandwidth, the delay, and the delay-jitter for this class of scheduling algo- 
rithms. The bandwidth to be reserved does not have to be known a priori. 
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3.1 Delay, Delay-Jitter, and Buffer Space 

Assume that the traffic source is constrained by a token bucket (cr, 6), where 
cr is the average token rate and 6 is token bucket size. For a given path p with 
n hops and the link capacity Ci , the provable end-to-end delay bound is given 
by (Zhang, 1995) 



r>/ i\ bn- Lmax , -^max , 

D(p,r,b) =- + + 2^-7^ + 2^ prop,- 

^ .=1 .=1 



( 1 ) 



where r (r > cr) is the bandwidth to be reserved, Lmax is the maximal packet 
size in the network, and prop,- is the propagation delay. The end-to-end delay- 
jitter bound and buffer space requirement at the h-th hop are given by 



T/ i.\ bn- Z/rnax 

J(p,r,6)= --f 

r r 



( 2 ) 



= b + h- 

Z'max* 



( 3 ) 



3.2 Path Selection 

A path is feasible for traffic with delay guarantees, if it meets the delay, delay- 
jitter, and buffer space requirements given in the Equations 1,2, and 3, respec- 
tively. There are two cases to consider. First, the bandwidth r to be reserved 
is known a priori. Second, r is not known and has to be calculated by the 
routing algorithm. The main results of this section are summarized in the 
following theorem: 

Theorem 1 The QoS routing problem of finding a path with delay^ delay- 
jitter, and/or buffer space constraints is solvable in polynomial time. If the 
bandwidth to be reserved is known a priori, a slightly modified version of the 
Bellman-Ford algorithm can solve it in S = 0(m - L), where m is the num- 
ber of nodes and L the number of links in the network. If the bandwidth to 
be reserved is unknown, an algorithm that iterates the modified version of the 
Bellman-Ford algorithm can solve it in E-S, where E is the number of all pos- 
sible residual bandwidth of links in the network. Moreover, if several paths are 
feasible, we can select one with any one of the following properties: minimum 
delay, minimum delay-jitter, or minimum hop count. 

Note that the maximal buffer space requirement of a path is determined 
by the path hop count. Thus, selecting a path with the minimum hop count 
reduces the maximal buffer space consumption. The following lemma will be 
frequently referenced in our discussion of path selection algorithms. 
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Lemma 1 Given a path-length function 1{P) = ^ ^ 

all links i, a bound d, and a hop bound N, Finding a path P from a source 
s to a destination d with l(P) < d and no more than N hops can be solved 
by the Bellman-Ford Algorithm in 0{N • E), where E is the number links in 
G. Moreover f we can identify from all feasible paths a path with the minimum 
hop count, or with the minimum length. 

Proof The Bellman-Ford algorithm (Bertsekas and Gallager, 1987) finds a 
shortest path step by step with increasing hop count: At the i-th step, a 
shortest path with at most i hops is found. The total number of steps is 
restricted to min{m, AT}, where m is the number of nodes in the network. 
The first feasible path found is the one with the minimum hop count. To find 
a path with the minimum length, we remember the paths found during each 
step and select the one with the minimum path length. □ 

(a) Delay Bound 

The problem of finding a path satisfying a given end-to-end delay bound is 
formulated as follows. 

Path Finding Problem (D-r): Given a delay bound d, a leaky bucket {a, b), 
and a bandwidth r (r > a) to reserve, find a path p with r < Rj (Vj E p), 
such that D{p,r,b) < d, where Rj is the residual bandwidth of link j. 

Path Finding Problem (D): Given a delay bound d and a leaky bucket 
(<7, 6), find a path p, such that D{p,r,b) < d for some r with <r < r < 
Rj (Vj E p), where Rj is the link residual bandwidth. 

Proposition 1 QoS routing problem (D-r) is solvable by both the Dijkstra 
and Bellman-Ford shortest-path algorithms. Moreover, if there are feasible 
paths, we can select one with the minimum delay. If the Bellman-Ford al- 
gorithm is used, we can select a feasible path with either the minimum delay 
or the minimum hop count. 

Proof. Find a shortest path P using either Dijkstra or Bellman-Ford algorithm 
(considering only those links with Ri > a) using the length function: 

= + + & HP) = ^- + '£tu) (4) 

* jeP 

If 1{P) > d, there is no path that meets the delay bound d. Otherwise, the 
P is a path with the minimum delay. If the Bellman- Ford algorithm is used, 
the first feasible path found is the one with the minimum hop count. □ 

Proposition 2 QoS routing problem (D) is solvable by iterating any single- 
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pair shortest-path algorithm over all possible residual link-bandwidth in E S 
time, where E is the number of possible residual link-bandwidths and S is the 
time for the shortest-path algorithm. If several paths are feasible, we can select 
one with the minimum delay. If the Bellman-Ford shortest-path algorithm is 
used in each iteration, we can select a feasible path with either the minimum 
delay or the minimum hop count. 



Proof. The difference with Proposition 1 is that the bandwidth r to be reserved 
is unknown. For a given path P, the delay can be reduced by increasing r. 
The maximal reservable bandwidth on path P is minjJJj \ j E P}. 

One would expect to use a shortest path algorithm using a length function 
as in Equation 4, setting r to the maximal reservable bandwidth on the partial 
path. The problem is that the maximal reservable bandwidth changes during 
the search. An earlier short path may turn into a long path when a link with 
small residual bandwidth is added to the path. To overcome this, we iterate 
the shortest-path algorithm over possible choices of link residual bandwidth. 
At each iteration, a fixed r is used in the length Equation 4, and only those 
links whose residual bandwidth are equal to or higher than r are considered. 
That is, for every r = Rk of some link k in the network, we define a length 
function Ir as follows: 



I / .\ -^max , -^max , 



jeP 



( 5 ) 



Using any shortest-path algorithm, we find a shortest path Pr from the source 
s to the destination d, such that there is no link j in Pr whose residual 
bandwidth Rj is less than r. We store r, Pr and lr{Pr) in a vector with E 
entries. After iterating r over all possible Rk, we search the whole vector to 
find a path Prnin whose length lr{Pmm) is minimal. We claim that the path 
F^min is the shortest delay path if r = minjiij | j G Pmin} is reserved. If it 
is not, there must be a path P' with a shorter delay than Pmin- Let P be 
min{P'- I j G P}, the maximal reservable bandwidth of the path P'. This 
r' must be the residual bandwidth of some links along the path P', and the 
residual bandwidth of all other links on P' must be no less than P. This is 
impossible since Pr» stored in the vector is a shorest delay path with r' < Rj . 

If the Bellman- Ford shortest-path algorithm is used to iterate over every r, 
we can select a feasible path with minimal hop count whose residual band- 
width is at least r. A feasible path with the minimum hop count can be 
selected from the result paths of all iterations. □ 



(b) Delay and Delay-Jitter Bounds 

The problem of finding a path satisfying both end-to-end delay and delay- 
jitter bounds can be formulated as: 
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Path Finding Problem (D-J-r): Given a delay bound d, a delay-jitter 
bound j, a leaky bucket (cr, 6), and a bandwidth r [r > <t) to reserve, find a 
path p with r < G p), Z)(p,r, 6) < d, and J(p,r, 6) < j, where Rj is 

the residual bandwidth of link j. 

Path Finding Problem (D-J): Given a delay bound d, a delay-jitter bound 
j, and a leaky bucket (a*, 6), find a path p, such that £)(p,r, 6) < d and 
^ j for some r with (t <r < Rj (Vj G p), where Rj is the residual 
bandwidth of link j. 

Proposition 3 QoS routing problem (D-J-r) is solvable by the Bellman-Ford 
algorithm in time m • L, where m is the number of nodes and L the number 
of links in the network. Moreover ^ if several paths are feasible, we can select 
one with any one of the following properties: minimum delay, minimum delay- 
jitter, or minimum hop count. 

Proof. We learn from Equation 2 that the hop count (n) is the only parameter 
that determines whether a delay-jitter bound j can be met: 

bn- Z/max 

- + iflF «<l-^ J 

• • -^max 

Thus, for any path, as long as its hop count is no more than iV” = L(^ 'J ~ 
^)/^maxJ, it will meet the delay-jitter bound j. We apply Lemma 1 using the 
distance function defined in Equation 4 with delay bound d, and hop count 
restriction N, to get our result. □ 

Proposition 4 QoS routing problem (D-J) is solvable in E • S, where E is 
the number of possible residual bandwidth of links in the network and S is the 
time for the Bellman-Ford algorithm. Moreover, if several paths are feasible, 
we can select one with any one of the following properties: minimum delay, 
minimum delay-jitter, or minimum hop count. 

Proof. Similar to the proof of Proposition 2, we iterate the Bellman- Ford 
shortest-path algorithm over all possible values of the link residual bandwidth 
Rk. At each iteration of r = the length function Ir of Equation 5 is used. 
The only difference is that, as in the proof of Proposition 3, we use the hop 
count Nr = [(r • j — 6)/LmaxJ to control the number of steps. Also, only those 
links with Ri >r are considered in each step. □ 

(c) Delay and Buffer Space Constraints 

The problem of finding a path satisfying both an end-to-end delay bound and 
buffer space constraints can be formulated as follows. 

Path Finding Problem (D-B-r): Given a delay bound d, a buffer space 
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constraint hu for each node t/, a leaky bucket {a, 6), and a bandwidth r {r > cr) 
to reserve. Find a path p, such that D(p,r, 6) < d, J5(p,6,/i) < b/j, and 
^ ^ ^ P)j where iij is the residual bandwidth of link j and b/» is the 

buffer space constraint for the node h hops from the source. 

Path Finding Problem (D-B): Given a delay bound d, a buffer space 
constraint b,^ for each node u, and a leaky bucket (u*, b). Find a path p such 
that £)(p,r, 6) < d, and B(p,6, /i) < b/j, for some r with < r < Rj (Vi € 
p), where R{ is the residual bandwidth of link j and b/» is the buffer space 
constraint for the node h hops away from the source. 

Proposition 5 QoS routing problem (D-B-r) is solvable by a modified ver- 
sion of the Bellman-Ford algorithm in 0{m • L), where m is the number of 
nodes and L the number of links in the network. Moreover, if several paths 
are feasible, we can select one with either the minimum delay or the minimum 
hop count. 

Proof. For each node u in the network, the buffer space constraint d^ defines 
a bound on the hop count Nu = [(du — 6)/i'maxJ, such that node u cannot 
appear in a path more than Nu hops away from the source. We define the same 
length function / as in Equation 4 and apply the Bellman- Ford shortest-path 
algorithm. During step h, we consider only those nodes with Nu > h. Finally, 
we select a path from the result paths of all steps. To conclude the proof, we 
need to show that if there exists a path P' from s to d that satisfies the delay 
d and hop count constraints Nj for all nodes j on the path, the modified 
Bellman-Ford algorithm must find a path P that has no more hops than P', 
/(P) < l{P^)j and P satisfies the hop count constraints for all nodes on the 
path. We use induction on h, the hop count of P'. The results clearly applies 
for h = 1. Assuming the result applies for h, we have to show that it applies 
for /i -h 1. Let w be the last node on the path P' prior to the destination of 
P', and Q' the path obtained by removing the last hop from P'. Using the 
induction hypothesis, there exists a path Q such that Q has no more hops than 
KQ) ^ Q satisfies the hop count constraints, and Q is the shortest 

path with no more than the h hops found by the Bellman- Ford algorithm. 
Since the path concatenating Q and the link from u; to d is a possible choice, 
the Bellman-Ford algorithm will find a path P with at most (h + 1) hops at 
the {h -f l)-th iteration, such that P satisfies hop count constraints and 

1{P) < 1{Q) + d) < l(Q') + l{w, d) = /(P'). □ 

Proposition 6 QoS routing problem (D-B) is solvable in 0{m • E^), where 
m is the number of nodes and E the number of links in the network. Moreover, 
if there are feasible paths, we can select one with either the minimum delay 
or with the minimum hop count. 
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Proof. Similar to the proof of Proposition 2, we iterate the modified version 
of the Bellman-Ford shortest-path algorithm in the proof of Proposition 5 
over all possible values of the link residual bandwidth Rk. At each iteration 
of r = Rk for some link Ar, the same length function Ir as in the proof of 
Proposition 2 is used. As in the proof of Proposition 5, for every node u, we 
use the hop count constraint to achieve the buffer space constraint b^, 
and let the Bellman-Ford shortest-path algorithm search only those nodes 
whose hop count bound are larger than the length of the path currently being 
considered and only those links with Ri >r. □ 

(d) Delay, Delay-Jitter, and Buffer Space Constraints 

The problem of finding a path satisfying delay, delay-jitter, and buffer space 
constraints can be formulated as follows. 

Path Finding Problem (D-J-B-r): Given a delay bound d, a delay-jitter 
bound j, and buffer space constraints b,^ for all the node u, a leaky bucket 
((7,6), and a bandwidth r {r > a) to reserve, find a path P, such that 
D(p, r, b) < d, J (p, r, 6) < j, B(p, 6, h) < b/j for all nodes on the path, and 
^ ^ ^ P) J where Rj is the link residual bandwidth and b/j is the buffer 

space constraint for the node with h hops from the source. 

Path Finding Problem (D-J-B): Given a delay bound d, a delay-jitter 
bound j, and buffer space constraints b,- for all the node i, and a leaky bucket 
((7, 6). Find a path p, such that D(p, r, 6) < (i, J(p, r, 6) < j, and B(p, 6, h) < 
hh for all nodes on the path, and for some r with (t < r < E p), where 

Ri is the link residual bandwidth and hh is the buffer space constraint for the 
node with h hops from the source. 

Proposition 7 QoS routing problem (D-J-B-r) is solvable by a modified 
version of the Bellman-Ford algorithm in 0{m • L), where m is the number of 
nodes and L the number of links in the network. Moreover ^ if there are feasible 
pathSf we can select one with any of the following properties: minimum delay, 
minimal delay-jitter, or minimum hop count. 

Proof. To meet the delay-jitter bound, we only need to control the number of 
steps in the algorithm in the proof of Proposition 5. □ 

Proposition 8 QoS routing problem (D-J-B) is solvable in E-S, where E is 
the number of all possible residual bandwidth of links in the network and S the 
time for the Bellman-Ford algrithm. Moreover, if there are feasible paths, we 
can select one with any of the following properties: minimum delay, minimum 
delay-jitter, or minimum hop count. 



Proof. The proof is similar to the proof of Proposition 6, except that the 
delay-jitter bound is used to limit the number of iterations. □ 




Quality -of ‘Service routing for traffic with performance guarantees 



125 



4 RELATED WORK 

For traffic with bandwidth guarantees, many studies have contributed QoS 
path selection algorithms. Breslau et.al. (1993) use an adaptive load-based 
routing algorithm. Wang and Crowcroft (1996) suggest shortest-widest path. 
Gawlick et.al. (1995) propose to use shortest path with exponential cost func- 
tion for permanent connections. Guerin et.al. (1996) suggest shortest-widest 
path. The dynamic-alternative path (Section 2) is based on results of dynamic 
alternative path for telecommunications networks (Gibbens and Kelley, 1988). 

For traffic with delay guarantees, several studies propose heuristics to tackle 
the NP-complete problem (Jaffe, 1984; Salama, et.al. 1997). Rampal (1995) 
evaluates several path selection algorithms. Wang and Crowcroft (1996) gives 
a careful study of the complexity of QoS path selection. Przygienda (1995) 
identifies a subset of path selections that can be done in poly normal time. 
Rosen et.al. (1991) propose an algorithm that is similar to the algorithm in 
Proposition 2 in a different setting. Guerin and Orda (1997) study more gen- 
eral QoS path selection problems when the routing information is inaccurate, 
and notice the algorithm of Proposition 2. Pornavilai et. al (1997) consider 
the problem of routing traffic with multiple QOS constraints, but they assume 
that the bandwidth to be reserved is known. 



5 CONCLUSION 

Quality-of-Service (QoS) routing selects paths that satisfy QoS constraints 
while achieving high resource efficiency. We study QoS routing for traffic re- 
quiring bandwidth and delay guarantees. For traffic with bandwidth guaran- 
tee, we present an initial evaluation of several routing algorithms. We show 
that several routing algorithms that favor paths with fewer hops (widest- 
shortest, shortest distance, and dynamic alternative path) perform well, while 
algorithms that favor longer paths (shortest- widest) result in less efficient re- 
source utilization. Selecting paths for traffic with end-to-end delay guaran- 
tees typically requires satisfying multiple QoS constraints, which is in general 
computationally intractable. However, the routing problem can be simplified 
if there are dependencies between the QoS constraints, as is the case in net- 
works using certain classes of scheduling algorithms. Specifically, we show that 
for a broad class of WFQ-like scheduling algorithms, finding a path satisfying 
bandwidth, delay, delay-jitter, and/or buffer space constraints is solvable by a 
modified version of the Bellman-Ford shortest-path algorithm in polynomial 
time. The bandwidth to be reserved is selected by the routing algorithm. 
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Abstract 

Quality of service (QoS) routing is important to support emerging multicast 
multimedia services. In this paper, we propose a routing metric and use it with 
two heuristic algorithms to find the multicast tree for guaranteed QoS services. 
The simulation results shows a marked improvement in network utilizations 
expressed in terms of cost over other proposed schemes like QOSPF. 

Keywords: Internet; POPS; Guaranteed QoS; QOSPF; Multimedia; Mul- 
ticast Routing. 



1 INTRODUCTION 

In this paper, we consider the problem of setting up the multicast route for a 
multicast session with guaranteed QoS requirements. The optimum tree in our 
formulation is a delay bounded minimum Steiner tree (Kompella et al 1993). 
We assume that we know the delay bound required by the application under 
consideration. 

The paper is organized as follows. In Section 2, we propose the routing 
metrics to be used with guaranteed QoS applications. In Section 3, we describe 
two heuristics that can use the routing metric. The performance analysis of 
the algorithms through simulation is given in Section 4. 



2 METRIC SELECTION FOR GUARANTEED QOS SESSIONS 

Guaranteed QoS applications (Shenker et al, 1996) need firm end-to-end bound 
on their packet delays and most of these applications will be multicast in na- 
ture. Here our goal is to find a multicast route that satisfies the end-to-end 
delay requirements of the session while having a tree with the minimum cost. 
In order to achieve our objective, we will first choose an appropriate routing 
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metric and then use a heuristic that attempts to optimize that metric. The 
choice of the metric should reflect the goals that we want to achieve. 

We assume that GPS-based scheduling schemes are being used at all the 
nodes. We use equal allocation scheme (Guerin et al. 1995) to allocate band- 
width at each hop to meet the QoS requirements. If required delay is dreqd 
then at each hop j, the allocated rate Rj is given by 



Rj = max 



h^{K-l)L 

dreqd "" 



Vj. 



( 1 ) 



K is the number of nodes and hence K — 1 is the number of hops in the 
path, b is the maximum burst size, L is the maximum packet length of the 
session and aj is the sum of the latency of the scheduler used at node j and 

propagation delay between node j — I and j. If 5 = minSj is the minimum 

i 

spare capacity or bottleneck bandwidth along the path then Rj < S. As a 
result, the ability to meet the delay requirement is heavily dependent upon 
5. In addition. Equation 1 indicates that for the same value of dreqd, a larger 
number of hops, i.e., K — 1, leads to a higher value of Rj and hence more 
network resources. Hence, to minimize network resource usage while meeting 
the required delay bound^we should attempt to And routes with large S 
and small K. We propose S/{K — 1) as the metric that the routing algorithm 
attempts to minimize. In the next section, we discuss two heuristic algorithms 
that use this metric. 

We define the following cost function for tree: 



Ct = 

i=i 




( 2 ) 



Rj is the actual rate allocated at node j and Sj is the spare capacity at node 
J. This cost function will be used to measure the performance of difference 
algorithms. 



3 ROUTING FOR GUARANTEED QOS SERVICES 



3.1 Shortest Path Algorithm 

The shortest path heuristic finds the shortest path (or best path) from the 
source to every destination. In our case, we find the path with largest S/{K—l) 
value for each destination. A tie is broken by choosing a path that has a lower 
propagation delay. The multicast tree is the union of all paths. 

This heuristic has been proposed for different metric by Wang (Wang et 
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Figure 1 (a) Cost of the tree versus Group size:Delay Bound= 3 
msec,(b)Percentage gain of NDF over Shortest path algorithm as delay bound 
variesiGroup Size=20 



al. 1996) and is similar to QOSPF (Shenker et al. 1996) being considered by 
IETF. 



3.2 Heuristics for the Constrained Steiner Tree 

This heuristics was proposed by Takahashi (Takahashi et al 1980) to find 
Steiner tree and is known as nearest destination first{NDF). Initially we choose 
the destination for which we can find the largest S/{K — 1) path from the 
source node. Then at each step we find the next nearest destination from the 
partially constructed tree using the same metric. It is repeated till all the 
destination nodes are included in the tree. A check is also made at every step 
to ensure that delay bound violation does not occur. 



4 SIMULATION RESULTS 

We used random euclidean graph for simulation. The spare capacity is uni- 
formly distributed between 20 Mbps and 120 Mbps. The maximum burst size 
was assumed to be 1000 bytes and the maximum length of the session un- 
der consideration is assumed to be 100 bytes. The link capacity is assumed 
to be 200 Mbps and the end-to-end delay bound of 3 msec was assumed for 
each source destination pair. We randomly generated ten different graphs con- 
taining 50 routers or switches. Nodes in the multicast group were randomly 
chosen. 

The simulations were run with the new routing metric introduced in this 
paper for both shortest path and nearest destination heuristic algorithms. 
Results were compared with those obtained for QOSPF routing scheme. 

The results of the simulation is being summarized in the Figure 1 (a). The 
results show that both shortest path and NDF using the proposed metric 
reduce cost compared to QOSPF. For a group size of 5, the cost reduction is 
35% with shortest path and 50% with NDF. Finally, Figure 1 b shows that, as 
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the desired delay bound becomes loose, the NDF shows better performance 
over the shortest path algorithm. However, at tighter delay bound there is 
not much improvement since the increase in cost due to tighter delay bound 
overshadows the advantages due to path sharing. 



5 CONCLUSIONS 

In this paper, we proposed a new routing metric for guaranteed GQoS appli- 
cations. We used the metric to find the multicast tree using shortest path and 
nearest destination first (NDF). The simulation results show that our metric 
performs better than those used by QOSPF in terms of network utilization. 
Furthermore, NDF heuristic performs better than shortest path heuristic. 
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Abstract 

This paper addresses issues in supporting Quality of Service (QoS)-based de- 
livery in mobile ad hoc networks. It first describes the generic character of 
mobile ad hoc networks (a.k.a. mobile packet radio networks), some ways in 
which they differ from non-wireless multihop networks, and the impact these 
differences have on supporting QoS-based delivery. It then briefly gives some 
thoughts on supporting QoS in these systems. 
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1 THE CONTEXT OF MOBILE AD HOC NETWORKING 

Providing strict QoS guarantees and robust service in the face of mobility are 
competing requirements. This competition is amply illustrated every time a 
cellular user is “dropped” due to mobility. Supporting mobile QoS on the 
“edge” of a fixed network (where a user is only a single wireless hop from a 
fixed infrastructure as in cellular or wireless LAN technology) is difficult, but 
supporting QoS without the aid of a fixed infrastructure is more so. 

A “mobile ad hoc network” (MANET) can be defined as an autonomous 
system of mobile routers connected by wireless links, the union of which form 
an arbitrary graph. MANETs have several salient characteristics: 

1) Dynamic (often rapidly changing) topologies-RonteTS are free to move ar- 
bitrarily; thus, the network topology-which is typically multihop-may change 
randomly and rapidly at unpredictable times. 

2) Bandwidth-constrained, variable capacity links-Wireless links will con- 
tinue to have significantly lower capacity than their hardwired counterparts. 
The realized throughput of wireless communications-after accounting for the 
effects of multiple access, fading, noise, and interference conditions, etc.-is 
often very much less than a radio’s maximum transmission rate. 



Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
© 1997 MP. Published by Chapman & Hall 




132 



Part Three QoS Routing 



3) Power- constrained operation-Some or all of the nodes in a mobile ad 
hoc network may rely on batteries for their energy. For these nodes, the most 
important system design criteria for optimization may be power conservation. 
Additionally, some envisioned networks (e.g. mobile military networks) may 
be very large (e.g. hundreds or thousands of nodes), which makes the problem 
of network control even more difficult. 

Viewed somewhat abstractly from an end-user, application-level perspec- 
tive, a communication network is simply one form of a communication “chan- 
nel”, albeit a somewhat complex one. There are many paths in the chan- 
nel through which information may flow, each with a potentially different 
capacity- some, all or none of which may meet a given user’s requirement. 

The network channel presented by a mobile ad hoc network differs signifi- 
cantly from that presented by a traditional, multihop, wide area network in 
two major ways: 

1) Time-varying channel capacity-ln a fixed network, the aggregate net- 
work capacity available between any two nodes is static. The task of network 
resource management is to dynamically allocate fractions of this static ca- 
pacity to the network’s users. A difficult task, but a simpler one than what 
follows. In a MANET, the aggregate network capacity available between any 
two points is continuously changing, and changing simultaneously due to mul- 
tiple dynamics on differing time scales. 

For example, there are fading effects resulting from user movement, shad- 
owing, multiuser interference, all of which change link capacity in a way that 
cannot be masked by the link layer, and which have a discernible effect at the 
application level (e.g. audio/ video reception). This affects the capacity of a 
given link or path on a given time scale. Also, radio links first tend to degrade 
slowly, then-due to the combined effects of coding breakdown and capture- 
based receiver behavior-simply dropout (referred to as link “failure”). This 
affects the existence of paths, and results in topological dynamics on a yet 
slower time scale. Reacting to these network capacity changes on multiple 
time scales requires protocol action. 

2) Relatively large percentage of capacity required for network control traffic- 
A MANET’s time-varying “network channel capacity” presents a more diffi- 
cult QoS support problem than that faced in non-wireless multihop networks. 
The differences between largely-static and highly-dynamic networks regard- 
ing resource allocation overhead can be thought of in terms of the following 
connection signaling phases: establishment, tear-down and maintenance. In 
largely-static networks, connections are established and torn down, but rarely 
modified once established. If modified, it’s usually due to an end-user request. 
However, in highly-dynamic networks, while connections are also established 
and torn down, they typically must be maintained and renegotiated in re- 
sponse to network topology dynamics. In many instances, this maintenance 
signaling outweighs the initial cost of establishing the connection. 

Hence, the amount of network control signaling required to maintain a given 
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QoS level would appear to be larger (normalized a per-connection basis) than 
would be required in the non-wireless case. Thus, in a context where the 
aggregate network capacity is smaller and time-varying, a larger percentage 
of it must be allocated to control overhead. The places extreme emphasis 
on the bandwidth efficiency and adaptivity (i.e. low time and communica- 
tion complexity) of the resource management signaling mechanism. In power- 
constrained networks, the processing complexity must be kept low as well. 



2 SUPPORTING QOS IN MANETS-WHAT IS FEASIBLE? 

In light of these considerations, what is a reasonable approach to providing 
QoS? Clearly, the approach should be adaptive, but how should one adapt? 
It is very easy-particularly in the context of mobile ad hoc networking-to 
get entangled in specifically the issue one is trying to avoid. Take, for ex- 
ample, congestion avoidance. How many complex algorithms-with additional 
complexity added specifically to avoid congestion-end up causing more con- 
gestion, due to their own overhead, than the simpler algorithms they replace? 

An answer to that question can be given-indirectly-by considering an- 
other problem, viz. store-and-forward datagram routing. In the context of 
fixed networks, it is long-established practice to use some form of short est- 
path routing for small to moderately-sized networks, and to resort to some 
form of hierarchical routing for large networks. Adaptive shortest-path rout- 
ing algorithms require a minimum amount of communication complexity to 
permit a shortest-path computation. For these algorithms, this translates-in 
one form or another-into what can be termed “far-reaching” control message 
propagation*. For small to moderately-sized, quasi-static networks, this com- 
plexity translates into a communication overhead that is acceptable (i.e. only 
a small fraction of network bandwidth is required for overhead). 

However, in dynamic multihop networks, a large amount of protocol adap- 
tation is required simply to handle topological changes. If the network is 
bandwidth-constrained, then the resultant routing control overhead may oc- 
cupy a large fraction of the network’s capacity, preventing transmission of data 
packets and consequently hurting overall data routing performance. To com- 
bat this problem, it is possible to design a “simpler” algorithm-i.e. one that 
supports a “looser” method of routing, where not even shortest-path routing 
is attempted. The Temporally-Ordered Routing Algorithm (TORA) (Park et 
al 1997) is an example of one such algorithm which has less communication 
complexity than a more complex algorithm (e.g. ideal link-state routing) that 
supports shortest-path routing, yet results in better routing performance in 



* Far-reaching message propagation results from the need to keep the shortest-path distance 
estimates up-to-date at each router. While some topological changes may cause only local- 
ized algorithmic reaction, others may require many or all of the nodes in the network to be 
informed-hence the term “far-reaching”. For a more in-depth discussion, see (Park et ai 
1997). 
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large, dynamic, bandwidth-constrained networks because of its lower commu- 
nication overhead (Park et al 1997). The conclusion here is that, in some 
cases, it is possible to obtain better performance by using algorithms which- 
at first glance-appear to solve a problem less optimally^ yet which, because of 
the competition for network bandwidth between data and control overhead, 
are really more efficient in terms of delivering more data bits per overhead 
bit expended. 

The previous discussion, while at the outset appearing to discuss rout- 
ing, is really a discussion on congestion-caused by routing-in MANETs. This 
points to a QoS architecture which seeks to appropriately balance network 
and application-level adaptivity to minimize aggregate QoS-related signaling 
to support a given QoS. Two approaches seem to warrant exploration: 

1) Minimal “Guaranteed” QoS- Essentially, in this approach a receiver 
specifies its needs (a minimal, required QoS level) and its wants (a desired 
QoS level). A signal may be hierarchically-encoded, and additional levels of 
fidelity (above a base level) may be requested by a connection and delivered 
by the network when possible as in (Corson et al 1995). The network does not 
inform the end-users when it cannot meet the desired QoS level, and the end- 
users’ application is expected to adapt to any QoS fluctuation between the 
minimal and desired QoS levels. This approach performs end-to-end admission 
control and management for the minimal requested QoS level only. Thus both 
network and application must adapt in this approach: the network adapts to 
changing channel conditions while trying to deliver the desired QoS, and the 
application adapts to any QoS fluctuations within its prescribed limits. 

2) “Probabilistic” QoS- The preceding approach assumes that voice and 
video (stream traffic) will be a significant fraction of the network traffic, which 
may, in fact, not be the case. In this light, a much more efficient approach to 
supporting QoS would be a probabilistic, prioritized QoS model involving the 
use of stateless virtual circuits (VC) at the network level. Such an approach 
permits instant reaction to routing changes, greatly reduces network control 
complexity and, through usage of a priority-based scheduling policy at the 
multiple access level as in HIPERLAN, nearly all VC-based packets make it 
through the network unimpeded. 
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Abstract 

With the emergence of multimedia technology, it has become important 
to be able to support a diverse set of client applications (simply called 
applications henceforth), each with its own Quality-of- Service (QoS) 
requirement. Such soft real-time applications exhibit remarkable loss 
tolerance capacity, provided the losses are well regulated. In this paper, 
we propose the notion of a noticeable loss, which directly relates loss 
pattern to the perceived QoS for an application, and use it to evalu- 
ate a novel resource management algorithm that attempts to provide 
acceptable QoS to individual applications. We apply our model to a 
real-world application, and provide simulation results to illustrate the 
performance of this algorithm. 

Keywords: deadlines, loss, end-to-end, scheduling 



1 Introduction 

With the dramatic improvements in processor and network speeds and data com- 
pression techniques that have occurred over the past few years, it has now become 
possible to support highly demanding multimedia applications such as video tele- 
conferencing. However, such applications each have a certain Quality of Service 
(QoS) requirement, which translates to delay-sensitive demand on the underlying 
resources. In order to exploit the gains in hardware and support multiple multimedia 
applications with their respective QoS requirements, application scAedu/tny becomes 
critical. This paper addresses the issue of scheduling applications so that their re- 
spective QoS requirements are satisfied in a Video Bridging system that facilitates 
live video conferencing. 

Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
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It is important to note that an application such as video conferencing requires 
access to multiple resources such as an encoder, the operating system (for access 
to memory and I/O) and the network. Hence, it becomes important to meet its 
QoS requirements at each of the individual resources which are shared by other 
applications, even though the application itself does not specify how its end-to-end 
QoS requirements have to be met at the individual resource nodes. Thus, effectively 
the scheduling problem becomes one of representing the QoS at each node and 
supporting it locally for a variety of applications. 

The QoS provided to any application is a function of the scheduling at (a) 
the network, and (h) the end-system server such as a video bridge. Ideally, there 
would be one scheduler managing resources at both the network and the server. 
Such a scheduler would have perfect knowledge of the current state of the entire 
system (network plus server), and would therefore be able to manage resources 
efficiently. However, such a global scheduler is infeasible, and we must make do with 
a distributed scheduling solution. The overall management strategy is to divide the 
problem into network and server components, and to solve them separately. That 
is, we decompose the overall scheduling problem into separate network and server 
scheduling problems. Even at the server, it is frequently infeasible to have a scheduler 
overseeing all the scheduling there: quite often, the server itself consists of many 
subunits, for which a distributed scheduler is the best practical solution. While 
much work has been done in supporting QoS requirements in the networks area 
[1, 3, 8, 9], relatively little research has been done to provide desired QoS levels in 
end-system servers. That is the topic of this paper. 

In this paper, we use a performance metric called Noticeable Loss Rate for evalu- 
ating the QoS offered to an application by a server. A task belonging to an applica- 
tion is considered lost if it misses its end-to-end deadline. The loss of a task is said 
to be noticeable if it occurs within an interval bounded by its previous loss instance 
and an application-specified time bound 6. Using NLR as a performance metric, we 
introduce the approach of Preemptive Abortion and Cycle Stealing (PACS), which 
attempts to reduce the NLR of various applications by exploiting their respective 
time bounds, which we call loss constraints. PACS carries out scheduling at in- 
dividual resource nodes such that all applications are provided an acceptable NLR. 
The effectiveness of the PACS scheme is evaluated using simulation experiments. 

As a motivation for this work, consider the video bridging system shown in Fig- 




Supporting multiple-tier QoS in a video bridging application 



139 



ure 1. This set-up is borrowed from a prototype at Bell Laboratories[4]. The input to 
the Multiplexer can arrive from different applications with disparate QoS require- 
ments, i.e., the streams can possess different rates of frame generation, deadlines 
and loss tolerance. Such a sharing of a bridging system among different applica- 
tions is often necessary for financial reasons. Once we have multiple applications 
contending for the same resource, scheduling becomes critical. The demultiplexed 
streams belonging to different applications will have to be scheduled by an Ap- 
plication Scheduler based on a delay-sensitive scheduling discipline such as Earliest 
Deadline First, or other real-time scheduling disciplines such as Rate Monotonic [10] 
or Cyclic Executive [2] in order to meet their timing requirements. So, the queue as- 
sociated with the Application Scheduler in Figure 1 can be a priority-ordered queue 
based on deadlines (or some other parameter) or a simple FIFO queue that is ser- 
viced cyclically. The output of the Application Scheduler is serviced by the Network 
Scheduler which breaks the application data into smaller sized cells and transmits 
them to the network. Note that the Network Scheduler may augment scheduling 
with traffic compliance policies, as in ATM systems. The video streams have to 
traverse many resources such as the Encoder, the Application Scheduler (typically 
the OS) and the Network Interface Unit. In summary, it is clear that a facility such 
as a video bridging system will have to support multiple applications with individual 
QoS requirements and such support will have to be on an end-to-end basis. 

The rest of the paper is organized as follows. We describe the system model 
and provide an overview of the solution approach in Section 2. The algorithm is 
described in Section 3, and numerical results are provided in Section 4. We conclude 
with a brief discussion in Section 5. Due to space limitations, the literature survey 
and parts of the original paper have been moved to [7]. 



2 System Model 

We make the following assumptions in this paper. 

1. There are multiple applications contending for the available resources. Applica- 
tions are classified according to their arrival pattern and QoS requirement. There 
are multiple classes of applications, each with its own distinct arrival pattern and 
QoS requirement. Each application class has its own priority assigned to it by a 
higher level entity such as a Call Admission Process, which is orthogonal to the 
scheduling problem addressed in here. 

2. An application with end-to-end processing requirement generates complex tasks. 
Each complex task consists of various suhtasks which execute at different resources. 
For example, processing a video frame generated by a camera is a complex task, 
consisting of subtasks for processing at the Encoder, the Operating System and the 
Network Interface. Subtasks of complex tasks belonging to different applications 
compete for resources. 

3. An application that generates complex tasks specifies an end-to-end deadline 
and an acceptable noticeable loss rate. The end-to-end deadline is the time by which 
the processing has to be completed at the end-system server such as the video bridge 
shown in Figure 1. The subtasks of a complex task have no deadlines associated 
with them; the only specified deadline is the end-to-end deadline associated with 
the complex task. A complex task which misses its end-to-end deadline is assumed 
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Figure 2: QoS Function 



lost. 

The loss of a complex task of an application belonging to a class i is said to be 
noticeable if the interval between its loss and the previous loss for that application is 
no greater than Sif where Si is a loss constraint speciHed for that application class. 
QoS is specified in terms of noticeable loss rate, NLR. 

Example 1. Figure 2 shows the QoS function for some application class. A* 
is the maximum acceptable NLR for that application class, i.e., if the noticeable 
loss rate is greater than A*, the QoS is no longer acceptable. Ideally, a scheduling 
algorithm should ensure that all applications are provided acceptable QoS. Note 
that the loss constraint and the acceptable NLR (ANLR) are related. For example, 
if ^ is 1 second, then, in the worst case, a task may be lost every 1 second and the 
QoS will still be acceptable to the application. Within a window of 1 second, if 30 
tasks are generated, then the ANLR is 1/30, i.e., 3.33%. 

The concept of a noticeable loss is important to effectively capture the loss 
tolerance capacity of soft real-time multimedia applications. It imposes a restriction 
on how a service provider such as a network or a server may carry out resource 
management while supporting a large number of requests and during periods of 
overload. Typically, most resource management strategies simply abort tasks during 
overloads; some actually do so within the bounds of normally accepted aggregate task 
loss. For example, an application may specify an aggregate task loss of 3%, but, this 
specification may allow too many consecutive losses to occur within a short window 
of time, which results in poor perceived quality for an application. Consecutive losses 
result in poor QoS for an application [13]. By placing a time bound on successive 
task losses, the concept of a noticeable loss forces a service provider to adhere to 
providing better perceived quality for an application. 

4. We do not know the exact execution time of each subtask; however, we do 
have an estimate. 

Given these conditions, we now address the problem of providing acceptable 
NLR for all applications belonging to various classes. 



3 The Algorithm 

There are two parts to our approach. In the first part, we concentrate on assigning 
virtual deadlines to subtasks so that their timely processing improves the chances 
of meeting the end-to-end deadline of the complex task that they are made of. 
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In the second part, we present a resource management scheme that attempts to 
meet the QoS requirements of various applications during periods of overload and 
unpredictable service requirements. The algorithm works with a given call admission 
control (CAC) process. Its impact on the OAC, though beneficial, is not the subject 
of this paper. 



3.1 Assigning Nodal QoS parameters 

An application only specifies an end-to-end deadline and an end-to-end NLR. These 
values have to be apportioned among various resources to facilitate nodal (i.e., 
corresponding to individual resource nodes) support including call admission and 
scheduling. Assigning nodal deadlines, which we call virtual deadlines, follows a 
similar approach to other work [5], but differs from them in how it assigns virtual 
deadlines. The subtasks belonging to various complex tasks are assigned virtual 
deadlines based on their flexihilityj which is defined as the ratio of available slack to 
estimated service time. The virtual deadlines are derived as follows. 

dt = Sx-^Sx/ifidf) ( 1 ) 

In the above expression, p is the mean task service time, and Sx is the estimated 
service time, d/ is used as a control variable to vary the second term on the RHS, 
which represents the amount of estimated available slack to a subtask. If we take 
the ratio of the second term on the RHS to the first term in Equation (1), we get 
l/{p,df), which is a constant for all the subtasks. Thus, the above assignment allo- 
cates equal flexibility to all subtasks at a node. Experimental work has shown equal 
flexibility to be a superior approach [5] (a detailed description of the aforementioned 
assignment, including its performance is presented in [6]). 

Recall that each application is associated with a loss constraint. This constraint 
can be apportioned among the various resource nodes of the server, thus converting 
a single loss constraint to individual loss constraints for each of these nodes. The 
apportionment process can follow any heuristic; in our own runs, we divide the loss 
constraint equally among all the nodes [9]. 



3.2 Handling Overloads and Unpredictable Service Times 

The flexibility-based deadline assignment results in a fair share of the resource for 
all subtasks and hence enhances their chances of meeting the deadline requirement. 
However, as the load increases (i.e., as more requests are admitted), subtasks may 
miss their assigned deadlines due to the variance in processing times. It is important 
to note that a virtual deadline expiration need not result in subtask abortion. In- 
stead, an attempt may be made to extract more processing time for such subtasks. 
It is clear that any scheme that attempts to extract more time for a tardy subtask 
would have to respect the QoS requirements of other tasks. 

We begin presenting the Preemptive Abortion and Cycle Stealng (PACS) scheme 
with a simple algorithm that follows a dual- timeline verification. See Figure 3. The 
estimated processing times of the two subtasks are shown by the rectangular boxes. 
In step 1, the algorithm verifies if a subtask in the task queue has already missed its 
assigned deadline. If it has, it is simply skipped and the verification is done for the 
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deadline of subtask i 




Figure 3: Dual-timeline verification 



next subtask in the queue. If a subtask has not already missed its assigned deadline, 
then, in step 2, the algorithm verifies if it will still meet its assigned deadline if the 
requesting subtask is allowed to continue in service. If so, the process is repeated for 
the next subtask in the queue. If no subtask that has not already missed its assigned 
deadline will miss it as a result of extending service to the requesting subtask, the 
request is honored. We now extend the concept of dual- timeline verification to allow 
for preemptive abortion. Note that in step 2 of the dual-timeline algorithm, a bot- 
tleneck subtask (one whose assigned deadline would expire if the requesting subtask 
is allowed to continue) may be eligible for preemptive abortion. A subtask is said to 
be eligible ioi preemptive abortion if the previous instance of loss associated with its 
application and the current time differ by more than the application’s nodal value 
of the loss constraint, since, then we can abort such a subtask without affecting 
the NLR for the application. Such an abortion can yield valuable time for a tardy 
subtask which might be in danger of experiencing a noticeable loss. 

The PACS algorithm is invoked when an assigned deadline expires without the 
subtask having finished its execution. At this time, the system scheduler - which 
manages the scheduling of various subtasks at a resource - has to decide whether 
it should allow the subtask to continue in service for an additional time, which is 
again estimated. The scheduler consults the PACS algorithm, which in turn decides 
whether the subtask can be allowed to continue its execution. The system scheduler 
is assumed to share the task-specific information, usually called Process Control 
Block (PCB) or Task Control Block (TCB) of various applications with the PACS 
algorithm. 

The pseudo-code of the algorithm is given in Figure 4. An illustration of the 
algorithm follows the pseudo-code. The parameters used in this algorithm are shown 
in Table 1. Note that a subtask belongs to an application, which in turn is a mem- 
ber of a class. So, while Ai refers to the previous instance of abortion of a subtask 
belonging to an application t. Si denotes the loss constraint of class i to which the 
application belongs. 



If the algorithm can accommodate the requesting subtask, then the amount of 
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/* Initialize. We start from subtask 1 in the queue */ 

^ = {0} 

^ = 0 

i = 1 /* a local variable */ 

T* = T /* T* is a local copy of system time T */ 

pl~| For all the subtasks in the subtask queue, 
if(T* >Di) 

/* subtask i has already missed its assigned deadline */ 

Increment t, goto next subtask 

/* Otherwise verify if subtask i will still meet its deadline if the requesting 
subtask is allowed to continue for X time units */ 
if (T* + Si + X) < jDi 

/* Yes */ T* = T* + Si, Increment », goto next subtask 
/* Otherwise, see if subtask t is eligible for preemptive abortion */ 
else 

if {T^Ai)> Si 

^ =z ^ V i /* subtask t is eligible */ 
else set B /* subtask i is not eligible */ 

/’•' Adjust the timeline to repeat the above process for next subtask */ 

I* See dual-timeline illustration */ 

T* = T* + Si 
Increment i 
End of loop 

If cardinality of ^ = 0 and B is not set 
/* no subtask needs to be aborted */ 
return (Jf ) 

If cardinality of ^ > 1, 

/* then we have candidates who are eligible for abortion */ 

Call AhortBaaedOnLoaaCn8i{) 

I* which picks a candidate from ^ a subtask with the largest processing 
time for preemptive abortion */ 

If cardinality of ^ = 0 and B is set, 

/* we do not have eligible candidates for abortion. So, now we pick 
candidates based on user-defined priorities Pi’s */ 

Call AboriBaaedOnPriorityi) 

/* which picks a lowest priority (assigned by Call Admission Control) 
subtask for abortion and returns its processing time as the amount of 
time salvagable */ 



Figure 4: PACS Algorithm 
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T 


The current system time 


X 


Extra amount of service needed by the requesting subtask 


Si 


The estimated service time of subtask t 


Di 


The assigned deadline of subtask i 


Ai 


Time of last abortion (preemptive or otherwise) 
of a subtask belonging to application t 


Si 


The nodal loss constraint of an application class t 


Pi 


The priority of class t 




Set of possible candidates for abortion 


e 


A Flag, when set, implies preemptive abortion should 
take place 


AhortBaaedOnLoasCnatO 


Aborts a subtask based on loss constraint 


AhartBaaedOnPriorityO 


Aborts a subtask based on the CAC-assigned priority 



Table 1: PACS Algorithm Parameters 
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Figure 5: An illustration of the algorithm 



salvaged time is returned to the scheduler, which allows the subtask to continue its 
service. Since the analysis is based on estimated execution times, it is possible that 
the requesting subtask may again undergo deadline expiration, in which case, the 
same process will be repeated. It is also possible that some other subtask which was 
involved in the analysis may itself undergo deadline violation for the same reason. 



3.3 Illustration of the PACS algorithm 

Example 2. Consider the subtasks shown in Figure 5. The subtask-specific 
information for each subtask is shown in Table 2. Note that such information is 
usually maintained as a part of the Process Control Block or Task Control Block 
data structure. 

The subtask To has undergone deadline expiration after executing for 2 units 
of time at time 52, and is requesting an additional processing time of 1 time unit 
(shown as a shaded box in Figure 5). At this time, the PACS algorithm is invoked 
to see if the request for additional time for subtask To can be honored. The PACS 
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Table 2: Subtask Parameters 



algorithm lays down the subtask profiles as shown in Figure 5(a), where the subtasks 
in the ready queue are scheduled from a new starting point determined by the 
amount of additonal request for subtask To . The subtasks T\ , T 3 and T 5 miss their 
assigned deadlines as a result of extending service to To . However, while checking 
the individual subtasks for their eligibility for preemptive abortion based on their 
nodal loss constraints and previous abortion instances, PACS finds ^ = {Ti, T3}. 
See Table 2 . The algorithm then picks subtask Ti for abortion, since its processing 
requirement is greater of the two subtasks in Since the amount of time salvaged 
is greater than the amount requested, (4 time units vs 1 time unit). To can continue 
its execution. The redrawn profiles are shown in Figure 5(b). 

For more detailed illustration of the algorithm, please refer to [7]. 



4 Performance Evaluation 

The system shown in Figure 1 was simulated. For each frame, there is an end-to- 
end deadline and each corresponding application specifies a loss constraint. The 
loss constraint refers to the loss constraint for B and P frames, I frames were 
not considered for preemptive abortion. The audio was assumed to have a separate 
channel and was not considered for preemptive abortion. So, the following discussion 
refers to video only. Also, we assume that the frame processing times at each node 
are estimated using exponential distribution^ . 

The frames from individual applications arrive at the multiplexer periodically, 
e.g., 30 frames every second. Even though the encoder outputs 30 compressed 
frames in a second, the output stream for each application from the encoder is 
not periodic due to the variance in compression times for individual &ames. This 
results in occasional bursty arrivals at the application and the network schedulers. 
Assuming that the encoder outputs 30 frames in a second for each application, both 
the application and the network scheduler have to process 30 frames in a second 
per application. We achieve this by invoking the respective scheduler once every 
33.33 ms, which then runs all the subtasks in its queue. The queue itself is ordered 
according to the non-preemptive Earliest Deadline First discipline, i.e. the subtask 
with the most urgent deadline runs first during each invocation. 

The performance measure of interest here is the cutoff load where the NLR 
^ Ofcourse the algorithm is not limited to any particular service time distribution. 
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crosses the ANLR for each application class. See Figure 2. We do this with, and 
without, PACS. For both the cases, however, the nodal allocation of deadlines and 
loss constraints is performed according to the description in Section 3.1. The metric 
Relative Gain (RG) is defined as follows. 



CUtoffpj^CS+ - <^'^toSpACS- 

cutoffopT - evtoffpj^cs- 



( 2 ) 



where cutoffpj^c and cutoffpj^c s- denote the cutoffs achieved with and with- 
out the PACS algorithm respectively. CutoffQpj^ is the upper bound on cutoff. Since 
cutoffop^p < 1, a lower bound of the relative gain is given by 



RGl = 



CUtoffpj^CS^ - 

1 — cutoffpj^cs- 



(3) 



A final note before we present the numerical results: we are not aware of similar 
work to compare our results with. 



4.1 Numerical Results 

We now focus on our first set of experiments. There are three classes of applications, each 
with a member application. The parameters values, the performance graphs, as well as the 
improvements made possible by the PACS algorithm for this set are presented in Figure 6 ^ . 
In Figure 6(a), the NLR is plotted versus the system load. It can be seen from this graph 
that Class 3 notices more losses than the other two due to its stricter loss constraint (even 
though at steady state all the three classes undergo approximately the same percentage of 
deadline misses). It can also be seen that the individual curves are spaced apart. 

Figure 6(b) shows the performance of the three classes with the PACS scheme. The 
following observations can be made from this figure. 

First, there is a considerable reduction in NLR for Class 2 and Class 3 applications. The 
overall improvement comes from two sources. First, where there is no abortion involved, 
simply additional processing time is borrowed from other subtasks without violating their 
assigned deadlines. This phenomenon alone appears to be the case until the load becomes 
moderately heavy (until about 0.6), and it continues along with preemptive abortion at loads 
beyond 0.6. Secondly, as the load increases (beyond 0.6), PACS aborts eligible candidates to 
make room for needy subtasks. Class 3 subtasks gain the most by aborting both Class 2 and 
Class 1 subtasks, since their loss constraints are less stringent. Class 2 subtasks compete 
with Class 3 subtasks to benefit from aborting Class 1 subtasks; they rarely get a chance to 
abort Class 3 subtasks. This explains why the improvement is higher for Class 3 subtasks 
compared to that for Class 2. There is a slight increase in NLR for Class 1 (represented by 
a negative RGj, of 2.3%) since a small percentage of its subtasks are aborted based on their 
priority. These priority-based abortions were counted as noticeable losses. However, recall 
that abortions that occur when the loss constraint allows PACS to do so are not noticeable 
losses. 

The reason why preemptive abortion adds to considerable improvement in NLR (along 
with cycle stealing only) can be attributed as follows. PACS is a greedy algorithm which 
chooses an eligible subtask with moxtmtim processing requirement when it has to perform 
abortion (based either on priority or loss constraint). And, it does this often during peri- 
ods of burstiness or overloads during which normally many subtasks are lost resulting in 

^A recent document by the Multimedia Communications Forum recommends using a 
terminal equipment (which includes video servers) delay of 200 ms and 150 ms for enhanced 
and premium quality multimedia communication respectively [11]. 
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Figure 6: Simulation Results: Case 1 



higher NLR. By greedily salvaging time during such periods, PACS dampens the effect of 
burstiness, thus reducing clustered losses which would result in poor QoS. 

Our next set of experiments include tighter end-to-end deadline and nodal deadline for 
all the three classes, as well as the addition of two more classes of applications. The details 
of these experiments and the performance of the PACS algorithm are available in [7]. 



5 Conclusion 

In this paper, we have presented a resomce management strategy for supporting multiple 
application classes with disparate QoS requirements. We have evaluated the performance 
of this scheme using a metric that suitably captures the loss tolerance abilities of soft real- 
time multimedia applications. Finally, we have shown through simulation experiments that 
the PACS approach indeed provides meaningfiil performance improvements in a practical 
application. 

Our future work involves applying our loss model and PACS to bundled multimedia 
such as audio, video and graphics. We are implementing the PACS algorithm in a stored 
video server (for distance learning) for supporting rate and loss guarantees to individual 
user connections. 
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Abstract 

This paper examines problems associated with display of live continuous 
media. Under the assumption that the network cannot guarantee the re- 
quired bounds on delay and jitter and the operating system scheduling is 
non-realtime, there is a need to accommodate the delay and jitter in the end 
systems in order to maintain a desirable Quality of Service (QoS). We propose 
a method of video playback which requires accurate estimation of display cycle 
time of video frames and the delay suffered by frames in the packet network. 
We apply various deterministic forecasting methods used in time series analy- 
sis on experimental data collected from video transmission. Suitable methods 
are recommended for display cycle time and delay estimation. 

Keywords 

Multimedia, playout, QoS, packetised video, time-series 



1 INTRODUCTION 

There has been a dramatic increase in the processing power of workstations 
and the bandwidth of high speed networks. This has given rise to new real-time 
applications such as multimedia applications. These applications have traffic 
characteristics and Quality of Service (QoS) requirements which are quite 
different from existing data-oriented applications. Delay jitter is an important 
performance metric for real-time traffic (Difference in end-end-delay is called 
jitter). Some factors responsible for causing jitter are: 

• the time required to digitise, compress and decompress video frames; 

• variation in delay in the network transport system; 

• operating system scheduling latencies. 
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Under the assumption that the network cannot guarantee the required 
bounds on delay and the operating system scheduling latency exits, there 
is a need to accommodate the delay jitter in the end systems. If the underly- 
ing network is connection less (individual packets may take different routes), 
the video frames may arrive at the destination out of sequence or after the 
time at which they should be displayed. A gap may result if a frame is not 
available for display. This may affect the quality of audio/ video playout. In 
our experiments we consider that a frame that is to be displayed at time t, 
must be completely present in the buffer at that time. It is then removed 
instantaneously, decoded and rendered (we will call the decoding, decompress 
and render time of video frame as display cycle). In practice, it would be 
displayed a short time later, depending on the speed of the decoding process. 

The rest of this paper is organised as follows. Section 2 describes an existing 
playout algorithm and its adaptation for video. Section 3 presents smoothing 
methods used to estimate the display cycle time. Section 4 presents results of 
applying these smoothing methods to traces collected for JPEG and MPEG 
video. Section 5 demonstrates the suitability of a new method for network 
delay estimation and spike detection. 



2 ADAPTIVE PLAYOUT ALGORITHM 

In this section we describe an adaptive method of video playout which has 
been adapted from audio playout method [Ramjee et o/., 1994]. 

The playout time for first packet Pi is calculated using : 

Pi = Si + DA + 71* j. (1) 

where 

Pi = Playout time for first frame i 
Si = Send time for first frame i 
n = l,2, •• 
j = jitter 

DA = Adapted delay value 

The playout point of all subsequent packets is calculated using : 



Pk = Pi + Sk — 5*. 



( 2 ) 



where A; = 2, 3, • • • 

For audio packets, playout time and display time are assumed to be the 
same as the time to playout the audio packet is very small. 
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Upon receipt of first video frame (in contrast to a packet in audio), playout 
time is estimated using the following formula: 

Pi = Si + DA -\-n* j - DR{. (3) 

where, DR{ = Average of display cycle 

In this approach we store the compressed video frames in a receiver buffer as 
they arrive [Jha and Pry, 1996]. A delay factor DAAn^j is added to the send 
time of frame. Section 5 describes the method of calculating the delay DA. 
The playout time for subsequent frames can be calculated in two ways. In the 
case of non-interactive sessions such as video on demand applications (where 
DA 4- n ♦ j can be as large as one second) subsequent frames are calculated as 

Pk = 4- DA 4“ n * j 4” IG — DRk- (4) 

where 

jk = 2,3 •• 

IG = Interframe gap (If the frame rate is 25 fps then IG = 1000/25 = 
40(ms)). 

For interactive sessions such as video-conferencing where there is a maxi- 
mum bound on end to end latency and IG is not know in advance, it would be 
preferable to maintain the timing relationship of arriving frames. A modified 
equation( 2) is used to calculate the playout time of subsequent frames 



Pk = Pi Sk — Si — DRk. 



( 5 ) 



Framel Frame2 Send 




Figure 1 Video playout method. 

In Figure 1 the playout point is DR units before the actual display time 
(dark black rectangles on the Display line of figure). H the estimate of DR 
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is accurate, we should be able to display frames close to the display time. 
In the case of continuous voice traffic, the factor DA -f n ♦ j is updated only 
between talkspurts. Video or music do not have talkspurts and silence periods. 
Campbell et al. [Campbell and Coulson, 1996] suggest changing this factor at 
the beginning of each group of pictures (GOP) for video stream using MPEG 
compression. 

In the next section, we present some well known deterministic forecasting 
methods used in time series analysis. We apply these methods on experimental 
data collected for video display cycle time in order to select the best method 
of forecasting. 



3 FORECASTING METHODS 

In this section we present three smoothing methods used to estimate the dis- 
play cycle. These deterministic methods have been selected because of their 
suitability to forecasting large numbers of items. The computing resources 
used by these smoothing methods are low in terms of both CPU and mem- 
ory. Basu et al. [Basu et a/., 1996] have used Auto-Regressive-Moving- Average 
(ARMA) to model the internet traffic. This model is not suitable for real-time 
scenario where updates are frequent. 



(a) Single Exponential Smoothing 

Single Exponential Smoothing (SES) is an attractive method of forecasting as 
it is computationally simple. The following equation is used to calculate the 
forecasted value: 



Fi^i = otXt H" (1 — ct)Ft, 0 < q: ^ 1. 



( 6 ) 



where. 

Ft = Forecasted value for tth period 
Xt = Current value 
a = Parameter chosen by user 



(b) Adaptive Response-Rate Single Smoothing 
The Adaptive-Response-Rate Single Exponential Smoothing Method (ARRSES) 
allows the value of a to change in response to changes in data pattern. The 
a value is automatically changed from period to period to allow for changes 
in the structure of data. Fluctuations in a can be controlled by putting an 
upper bound on how much a is allowed to change from one period to the 
next [Makridakis et al, 1983]. 
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Ft^i is calculated using equation( 6) where, 



1 1 

at+1 1 . 


(7) 


Et = 0et + (l-l3)Et-u 0<I3<1. 


(8) 


Mt = P\et\ + {l-P)Mt-i- 


(9) 


where 




P = Parameter chosen by user 

and et is the error term defined by equation 





et = Xt - Ft. (10) 

(c) Holt’s Two-Parameter Method 

Two-parameter forecasting was done with Holt’s linear exponential smooth- 
ing, which smoothes the trend values separately. This provides greater flex- 
ibility, since it allows the trend to be smoothed with a different parameter 
than that used on the original series. The forecast can be found using two 
smoothing constants (with values between 0 and 1) and the three equations: 

St = aXt + (1 - a){St-i + bt-i), 0 < a < 1. (11) 

bt = 7{St - 5t-i) -h (1 - 7)6t-i, 0 < 7 < 1. (12) 

Ft = 5t + 6t. (13) 



where 

St = Smoothed Value for tth period 
a, 7 = Parameters chosen by user 



4 DISPLAY CYCLE TIME ESTIMATE 



4.1 Analysis of JPEG Data 

In order to evaluate the best approach for forecasting these values, we mea- 
sured the display cycle time for two different video clips using JPEG compres- 
sion on Sun Ultra Sparc-1 machines. The lion.jpg clip is a stampede fragment 
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(a) lion.jpg 



(b) 8ong.jpg 



Figure 2 Frame Size vs Display Cycle Time. 

(5925 frames) from the movie Lion King with lots of movement and frequent 
scene changes. The second clip song.jpg is from a popular English song which 
has comparatively less movement and scene changes (2558 frames). Ftc was 
used to decompress and render the frames [McCanne and Jacobson, 1995]. 
FVames were received from another workstation on the same local area net- 
work at an average of 25fps rate. Frame size in both cases is 352 ♦ 288 pixels 
(GIF). 

(a) Frame Size and Display cycle Time 

In order to estimate the display cycle we plotted frame size (compressed) 
versus the display cycle time of the two video clips. Figure 2 shows these 
plots. As is evident from the plots, there is little correlation between the 
frame size and display cycle time. 

(b) Model Comparison Criterion 

We will compare our models on the basis of their Mean Absolute Deviation 
(MAD). This is the arithmetic mean of the absolute deviations of each forecast 
from its actual value. That is, 

(14) 

n 

Cen et al [Cen et al, 1995] used Mean Squared Error (MSE) to compare 
the effectiveness of a particular playback method. MSE squares the errors and 
so penalises a forecasting technique much more for large errors than for small 
errors. On the other hand, MAD penalises all errors in direct proportion to 
their absolute size. In the context of interactive video playback, we find little 
a priori justification for using squared error penalties. On a purely practical 
level, the MSE is also very susceptible to infiuence by ’’outliers”, unlike the 
MAD. For these reasons we used only the MAD criterion in our experiments. 
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Figure 3 Frame Sequence No. vs Display Cycle Time for 1st 500 frames. 



Table 1 Mean absolute deviation for JPEG models. 







Mean Absolute deviation 


Method 


Parameters 


lion.jpg 


song.jpg 


SES 


a = .125 


2.45 


3.96 




a = .4 


2.16 


3.36 




a = .6 


2.26 


3.30 




a = .8 


2.46 


3.33 


HOLT 


a = .4 7 = .1 


2.22 


3.53 




a = .6 7 = .1 


2.34 


3.48 




a = .8 7 = .2 


2.66 


3.66 


ARRSES 


P = .2 


2.09 


3.49 




/3 = .2 limit = .6 


2.11 


3.37 



4.2 Models Tested 

Most commonly researchers have used the digital filters which are SES fore- 
casts with a = 1/16 or a = 1/8. We calculated the forecasted values using 
these parameters as well as a = .4, .6, .8. Since the display cycle time had 
an apparent trend (Figure 3), we also tried Holt’s two-parameter forecasting 
method. A wide variety of (a, 7) pairs were tried with the best choice being 
(.4,.l). 

Table 1 shows the calculated Mean Absolute Deviations using the various 
forecasting methods. The ARRSES with = .2 performs best for lion.jpg 
{MAD = 2.09). The SES (a = .4) is very close ( MAD = 2.11). For songjpg 
SES(a = .6) gives the lowest MAD (3.30). Plots of the forecast errors did 
not show any noticeable difference between the various forecasting meth- 
ods [Jha and Wright, 1997]. 
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4.3 Analysis of MPEG Frames 

In this section we analysed traces collected for 900 frames from an MPEG clip 
flt.mpg (240 x 352 pixels). The fltmpg movie was coded using the following 
sequence IBBPBBPBBPBBPBB. Since Vic does not support MPEG format, 
we used the Berkeley Mpeg^play tool to collect traces [Rowe and Smith, 1992]. 
Mpeg.play doesn’t support network communication and hence the display cy- 
cle time was not affected by packet arrival. 

(a) MPEG Frame Size and Display Cycle Time 

In order to estimate the display cycle we plotted frame size (compressed) ver- 
sus the display cycle time of the video clip flt.mpg. Figure 4 shows that the 
frame size and display cycle time seem to be correlated. We did not examine 
this phenomenon any further as our results for JPEG frames in the networking 
environment (using Vic) were not highly correlated. Also any correlation be- 
tween the frame size and display cycle time will be affected by the processing 
power of a host system. 




Figure 4 Frame Size(bytes) vs 
Display Cycle time. 



Figure 5 Display Cylce Time for 
I, P and B Frames flt.mpg. 



(b) Models Tested 

The MPEG display cycle times were forecast using the same models as for 
the JPEG clips. The initial results are shown in the Table 2. Note that the 
MPEG stream consists of I , P and B frames and decoding time for these 
3 types of frames vary. The averages for display cycle time of I, P and B 
frames are 36.7, 31.1 and 22.6 ms for the flt.mpg clip. We plot the decode 
time of these frames separately in Figure 5. The figure clearly shows that I 
frame takes longest followed by P and then B. We then used the smoothers 
separately on each type of frame. FVom the results in Table 3 it is evident 
that the value of MAD has dropped substantially for every type of frame. We 
conclude that forecasts of the 3 types of frames (I, P & B) should be stored 
separately as this provides a much better estimate. Table 3 shows that SES 
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Table 2 MAD for MPEG’s IPB frames (combined). 



Method 


Parameters 


MAD(fltmpg) 


SES 


a = .125 


4.68 




a = .4 


5.34 




a = .8 


6.43 


HOLT 


a = .4 7 = .1 


5.65 




a = .6 7 = .1 


6.14 




a = .4 7 = .4 


5.78 




a = .2 7 = .8 


5.31 


ARRSES 


^ = .2 


5.97 



(a = .4) performs better for P and B frames (in terms of MAD) in comparison 
to ARRSES but is marginally worst for I frames. 



Table 3 MAD for MPEG I,P and B frames. 



Clip fltmpg 


Method 


Frame count 


Parameters 


MAD 


I — frame 


SES 


69 


a = .4 


2.67 




ARRSES 




/3 = .2 


2.57 


P — frame 


SES 


231 


a = .4 


1.15 




ARRSES 




j3 = .2 


1.2 


B — frame 


SES 


600 


a = .4 


1.06 




ARRSES 




/3 = .2 


1.08 


I — frame 


SES 


69 


a z=z A 


2.67 



5 DELAY ESTIMATION/SPIKE DETECTION ALGORITHM 

In the section 3 we looked at an adaptive method of playout for audio- 
video frames. The success of this method depends on the accuracy of esti- 
mating/forecasting the value of the end to end delay of packets. Analysis of 
delay characteristics has been carried out by several researchers [Bolot, 1993] 
by collecting traces from the Internet. These traces show occurrence of fre- 
quent spikes which last for several milliseconds. A spike is characterised by 
a sudden large increase in the end to end delay of packets. The delay trace 
plotted in Figure 6 was collected between a host at the University of Tech- 
nology, Sydney (mill.socs.uts.edu.au) and Columbia University, New York 
(sutton.cs.columbia.edu). These traces were collected using a modified ver- 
sion of the ping utility which sends a packet to specified destination every 
20 ms. The number of hops followed by each packet was more than 20. The 
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Table 4 Mean absolute deviations for delay. 







Mean Absolute Deviation 


Method 


Parameters 


normal 


spike 


SES 


a = .125 (RFC 793) 


5.70 


25.24 




a = .4 


3.05 


10.30 


HOLT 


a = .4 7 = .1 


3.62 


11.94 


ARRSES 


0 = .2 no limit 


3.24 


8.21 



spike was created artificially to resemble the spikes observed by Ramjee et 
al [Ramjee et a/., 1994]. 



5.1 Conventional Delay Estimation/Spike Detection 
Algorithm 

Most audio tools estimate the delay factor using estimators described by Ja- 
cobson [Jacobson, 1988]. The equations used for this purpose are similar to 
equations( 6),( 8),( 10). 

An adaptive algorithm which explicitly adjusts to sharp spikes like increases 
in packet delay has been suggested by Ramjee. If there is no spike then delay 
is updated using equation 6. In this method a threshold value of delay is used 
to detect the spike. The threshold value is arbitrarily set to 800ms. If a spike 
is detected, a different formula is used to estimate delay : 



= Ft Xt^i — Xt> 



(15) 



5.2 Proposed Delay Estimation/Spike Detection Algorithm 

We propose the self-adjusting ARRSES method, described in section 3, which 
estimates delay value and adapts to spikes automatically. There is no need to 
set any threshold value nor provide a separate formula to deal with spikes. 
Table 4 shows the Mean Absolute Deviation (MAD) for the trace without 
spikes (normal) and with spike. In terms of MAD, the SES method with 
a = .4 performs better than the other methods but is only marginally better 
than ARRSES. For the trace with spike, ARRSES outperforms all the other 
methods. Figure 6 shows the comparison of ARRSES method with SES. SES 
method with a = .125 performs worst. Holt’s 2 parameter over estimates the 
values most of the time. 

In order to verify the suitability of the ARRSES method for spikes of lesser 
magnitude, delays were forecasted for a simulated trace containing spikes of 
different magnitudes. These spikes ranged down from the spike in Figure 6 
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Comparison of Delay Estimate With spike 




Figure 6 ARRSES .2 vs SES .4 



which was about four times the average delay, to a spike which was only about 
twice the average delay. The ARRSES method tracks spikes of any magnitude 
with success [Jha and Wright, 1997]. 



6 CONCLUSION AND FUTURE WORK 

This paper has considered problems associated with the playback of video 
streams. In particular the paper has considered display cycle time estimation 
as important factor in achieving a required quality of service. Estimation of 
display cycle time of video frames was performed using several forecasting 
methods. We conclude that the SES with a = .4 to .6 works well for video 
frames. We have also demonstrated that the ARRSES works well for estimat- 
ing end-to-end delay of packets even in the presence of small and large spikes. 
One possible disadvantage in using the ARRSES is that the a value can fluc- 
tuate a lot. This can be overcome by putting an upper bound on how much a 
can change from one period to the next. Future work will include evaluation 
of bounds on a. 
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Abstract 

We present a CPU scheduling model aimed at satisfying multimedia presentation 
temporal QoS requirements. The model is based on a playout specification and a 
runtime application structure that allows workahead processing, and quality degra- 
dation for delay or overload situations. 

Keywords 

Operating system QoS support for multimedia, synchronization, CPU scheduling. 



1 INTRODUCTION 

Multimedia temporal QoS requirements include both individual stream’s continuity 
and inter-stream synchronization. In order for an operating system to manage these 
QoS requirements, its CPU scheduler needs an explicit knowledge of data temporal 
characteristics to perform a scheduling aimed at respecting them. This is not the case 
in existing general purpose OSs (Nieh etal 1993). Currently, application developers 
have to define application-specific temporal QoS enforcement methods which can 
result in unacceptable presentation quality, since CPU scheduling is decoupled from 
decisions taken within these methods (Bourges Waldegg et al 1996). 

In a general purpose OS, users may accept a degraded quality presentation under 
varying load conditions. Integrating synchronization and quality adaptation into the 
system scheduler can help to take more accurate decisions and to m^e a better use 
of the CPU resource. This integration also provides programmers with a generic sup- 
port which they can use to build multimedia applications. 

So we have developed a CPU scheduling model for adaptive multimedia presen- 
tation applications, that integrates synchronization and adaptation support. The mod- 
el is composed of an application structure aimed at minimizing degradation for 
streams with intensive-CPU needs; a QoS and playout scenario specification to 
transmit QoS requirements to the kernel; and an on-line scheduling algorithm. 
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2 QOS BASED SCHEDULING MODEL 

We will briefly describe the components of our scheduling model. For a more de- 
tailed description please refer to (Bourges Waldegg 1997). 

Presentation runtime structure 

During a multimedia presentation, data units (DUs) composing continuous media 
streams are obtained from network or disk. Before they can be presented, DUs may 
need a more or less important amount of processing. Continuity of a stream is en- 
sured by the sequential presentation of DUs at periodic instants. 

Note that only the DU’s presentation needs strictly periodic attention. Reading 
and processing of a DU can be anticipated and further performed in a workahead ba- 
sis if CPU time is available, absorbing network delay and processing time variations, 
minimizing thus presentation deadline violations. 

Data must be manipulated by adapted execution structures (the scheduling units 
in the kernel, which we call threads). We propose an execution model that performs 
each activity (reading, processing and presentation or degradation) in an individual 
thread, an application consists then of a set of these threads for each stream. 

QoS parameters and play out scenario description 

The temporal QoS specification of a multimedia presentation application includes 
parameters such as individual streams’ rates, tolerable jitter for DU presentation, and 
tolerable skew between streams. 

For describing the playout scenario, we use the Timed Stream Petri Net (TSPN) 
model (Senac et al 1994). This model is a timed extension of Petri Nets, which adds 
firing intervals to arcs outgoing from places. A continuous media stream is then 
modelled by a sequential composition of places and transitions, firing intervals allow 
for the expression of jitter and variable processing times. Typed inter-stream syn- 
chronization points are modelled by transitions with several input arcs. Figure 1 
shows an example of a TSPN modelling an audio/video presentation. 




On-line CPU Scheduling Algorithm 

At initialization, the application transmits its QoS parameters and playout scenario 
to the kernel. The scheduler then executes the TSPN representing the application. 

If a transition is Arable at scheduling instant 0, presentation threads correspond- 
ing to all streams involved in the transition are scheduled in internal priority order 
(which reflects the importance of the stream for inter-stream synchronization). If a 
presentation thread is not ready, a degradation thread is scheduled. 

If there’s no Arable transition at instant 0, reading/processing threads in non- 
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workahead state are scheduled in deadline order, the deadline being the lower bound 
of the dynamic temporal validity interval corresponding to the associated arc (whose 
values depend on the static interval and execution state). Reading/processing threads 
are scheduled for a duration of one time quantum, a value which reflects processing 
needs for each stream. 

If at instant 0 there are no reading/processing threads in nonworkahead state, 
workahead threads can start to be scheduled in a round robin basis. 

In summary, the decision algorithm will schedule in priority: 

• presentation threads when scheduling instant belongs to firing interval, in inter- 
nal priority order; 

• nonwork^ead reading/processing threads in deadline order; 

• workahead processing/reading threads in round-robin. 



3 EXAMPLE 

We illustrate our scheduling model with an audio/video software decoding/presenta- 
tion application. Let us consider QoS demands as follows: 16 images/s, maximum 
skew between audio and video = 80 ms. The TSPN depicted in Figure 1 corresponds 
to this QoS specification, with a synchronization interval of half a second. The audio 
stream, which is more sensible to degradation than the video flow, is set as the master 
stream for inter-stream transitions. As video processing is more CPU demanding 
than audio processing, we fix the time quantum for video to be 30 ms, and the time 
quantum for audio to be 5 ms. 

We consider that video images need the following reading/processing times: 
vi=120 ms, V2 = 45 ms, V3 = 45 ms, V4 = 80 ms, V5 = 45 ms, vg = 45 ms and V7 = 120 
ms. Presentation threads need 10 ms each time an image is displayed or an audio 
block is sent to device. The audio block needs 40 ms to be processed. Note that these 
values are not known a-priori by the scheduler. We consider also that processing of 
image Vj had been scheduled in a workahead basis, and at the time the synchroniza- 
tion interval starts, it has progressed 1 10 ms. 

The schedule obtained with our algorithm is shown in Figure 2. Note that all vid- 
eo images excepting image V7 are presented within their validity intervals even 
though some of their processing times exceed the stream’s period. Image V7 was not 
ready at time transition t7 needed to be fired (0 = 427.5 ms). A video degradation 
thread was thus scheduled, the degradation policy consists of just rejecting the im- 
age, and advancing to the reading/processing of the next image. At the end of the 
synchronization interval, audio block aj is ready for presentation, and inter-stream 
transition tg is fired at time 0 = 472.5, which is a temporally correct value. 



4 CONCLUSION AND PERSPECTIVES 

We have presented a QoS based scheduling model for adaptive multimedia presen- 
tation applications, which offers a support for synchronization and adaptation at a 
lower level, saving thus decision layers that can cause inaccuracy. Degradation de- 
cided by the scheduler is useful for a better resource utilization. Finally, with our run- 
time structure we allow for anticipation and workahead processing that can be useful 
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Figure 2 MPEG audio/video schedule. 



in overload situations. 

We are currently working on the implementation of our model in the Solaris op- 
erating system. Problems related to priority calculation costs are being analyzed. 



5 REFERENCES 

Bourges Waldegg, D., Lagha, N. and Le Narzul, J.P. Multimedia Applications on a 
UNIX SVR4 Kernel: Performance Study. In Proceedings of the 3rd Intemation- 
al COST 237 Workshop on Multimedia Telecommunications and Applications, 
Barcelona, Spain, November 1996. 

Bourges Waldegg, D. A CPU Scheduling Model for Respecting Temporal QoS in 
General Purpose Operating Systems. ENST Bretagne Technical Report, 1997. 

Nieh, J., Hanko, J.C., Northcutt, J.D. and Wall, G.A. - SVR4 UNIX Scheduler Un- 
acceptable for Multimedia Applications. In Proceedings of the 4th International 
Workshop on Network and Operating System Support for Digital Audio and Vid^ 
eo, Lancaster, UK, November 1993. 

S6nac, P., Diaz, M. and de Saqui-Sannes, Pierre. Towards a Formal Specification of 
Multimedia Synchronization Scenarios. Annals of Telecommunications, Vol. 
49,bT5-6, 1994. 



6 BIOGRAPHY 

Daniela Bourges Waldegg was bom in Mexico City, in 1970. She obtained an Elec- 
trical Engineering degree in 1993 from the “Universidad Aut6noma Metropolitana”, 
in Mexico City and a Computer Science “Dipl6me d’Etudes Approfondies” from 
“University de Rennes 1” in 1994. She is currently a PhD student at the Networks 
and Multimedia Department of the “Ecole Nationale Sup^rieure des Tyidcommuni- 
cations de Bretagne” in Rennes, France, supported by a grant from the Mexican Na- 
tional Council for Science and Technology (CONACyT). 




18 

Adaptive video applications for non- 
QoS networks 

S. Jacobs and A. Eleftheriadis 
Department of Electrical Engineering 
Columbia University, New York, NY 10027, USA 
{ sej, eleftj @ ee. Columbia, edu 



Abstract 

We propose an architecture which can support video services in networks which 
have no Quality of Services (QoS) guarantees. We demonstrate that there is a need 
for such services today and also in the future, when (JoS will be built into most 
networks. We then describe our current Internet-based system, which combines 
both image processing and networking techniques in order to provide good quality 
video without harming the performance of the Internet. TTiese techniques are 
shown to be superior to previous work for the environment of video services 
operating in the Internet. 



Keywords 

Internet video, adaptive video, non-QoS networks, TCP congestion control 



1 INTRODUCTION 

The underlying technologies of today’s Internet are not sufficient to support 
Quality of Service (QoS) guarantees. The evolution of the base technologies of the 
Internet could result in any number of possibilities, including ATM backbones, IP 
switching, or fully deployed ATM networks. Regardless of the specifics, the 
general consensus is that the network infrastructure of the future will have QoS and 
that users will be able to request connections with or without QoS. 

Certainly connections which reserve resources will demand a higher cost and users 
may not always want to pay this extra cost for a particular video service. If a user 
is watching a movie, perhaps it would be worthwhile. However, just browsing a 
video database may not warrant the extra cost since the user may browse many 
video streams before deciding on the one that is being sought. Thus, some video 
services may not warrant the extra cost of QoS. 

Another motivation for being able to provide good quality video services without 
QoS is that some networks may never be able to provide QoS guarantees. Wireless 
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networks fit into this category because there may be no way to guarantee a certain 
bandwidth when so many other variables exist that affect the throughput on the 
wireless link. 

The technique for developing video services without QoS involves an explicit 
attempt at avoiding network congestion. Clearly, network congestion hurts the 
performance of all users of the network. The goal is to send only the data that can 
fit into the network at a particular time. This requires both a networking and an 
image processing approach. From the networking perspective, an estimate of the 
available bandwidth in the network must be found. Then, from the image 
processing perspective, a technique for shaping the compressed video into that 
available bandwidth is necessary. In the next sections we discuss previous work as 
well as our proposal for both the networking and image processing techniques. 



2 BANDWIDTH ESTIMATION 

As real-time services have become more prevalent over the last few years, there 
has been a growing concern that the current Internet infrastructure may not be able 
to support them, leading perhaps, to a “congestion collapse.” This is a valid 
concern in general since many real-time services send their bits through the 
network without concern for congestion control or avoidance. 

It is important to ensure that the technique for estimating the bandwidth provides 
fairness among different traffic types, i.e. ftp, http, audio, video, etc. Our 
architecture uses the TCP Congestion Control (TCP-CC) algorithm as a congestion 
indicator. TCP is not used for transport and retransmissions are performed 
selectively. An algorithm which always retransmits increases the delay, which in 
general, is unacceptable for real-time applications and certainly for video. 

The reason for using TCP-CC as an indication of available bandwidth is that TCP 
streams work well together; today’s Internet is proof of that. They operate 
according to a greedy but “socially-minded” and cooperative algorithm which 
attempts to get as much bandwidth as possible, but backs off substantially during 
congestion. Using TCP-CC can make real-time traffic look as harmless as a file 
transfer to the network and still maintain relatively low delay (Jacobs 1996). 

The Internet is only one type of network which has no QoS guarantees. ATM- 
ABR provides a guaranteed minimum QoS, but informs the server when more 
bandwidth is available. In this case, the bandwidth estimate is explicit in that the 
network furnishes the exact bandwidth which is available. Also, as mentioned 
earlier, wireless may never have QoS guarantees. 
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3 ADAPTABLE MEDIA 

Just as the Internet is one type of network which has no QoS guarantees, video is 
only one type of media which can be adapted on the fly. For environments where 
minimal delay is more important than perfect quality, the rates of both audio and 
still images can be adapted. Thus, although this paper focuses on video and the 
Internet, some of the concepts also apply to any combination of non-QoS network 
and adaptable media, i.e. wireless and audio. 

Techniques for adapting compressed video on the fly have been limited in the past. 
One technique is to adjust the quantization parameters at the encoder based on the 
state of the network (Ortega 1995). Although this works quite well for live video, 
it cannot work for precompressed streams. Another commonly used technique for 
changing the bit rate of video is to drop frames (Chen 1996). However, frame 
dropping alone is a crude technique which provides only a coarse approximation to 
the available bandwidth since the smallest unit of data which can be removed is an 
entire frame. Although subjective tests have not been completed, it seems intuitive 
that very low frame rate video is perceived as less valuable for many applications. 

To solve this problem, we developed a technique called Dynamic Rate Shaping 
(DRS) (Eleftheriadis 1995). DRS provides the ability to dynamically change the 
bit rate of a precompressed stream. In its simplest form, DRS selectively drops 
coefficients from the MPEG-1 or MPEG-2 bit stream which are least important in 
terms of image quality. 

DRS operates on the compressed video bit stream, eliminating DCT coefficients 
run-lengths. The coefficients to be eliminated are determined using Lagrangian 
optimization, resulting from an operational rate-distortion formulation. The 
problem is complicated by the fact that MPEG coding utilizes predictive and 
interpolative modes for motion compensation, and thus any modification of the bit 
stream will result in error propagation. We have experimentally shown in 
(Eleftheriadis 1995) that, if decisions within each frame are optimal, then ignoring 
the accumulated error does not impact the quality in any way. Thus the algorithm 
can operate in a memoryless mode which has significantly less complexity, while 
achieving essentially optimal (within 0.3 dB) performance. Also, DRS is much 
less complex than a complete decoder, making it feasible to run on a video server. 

DRS can meet any reasonable bandwidth estimate exactly. This means that the 
bandwidth estimate is more fully utilized. It also maintains the original frame rate 
of the video. Lastly, DRS decouples the adaptable media from the encoder so that 
it can be used for both live and stored video streams. A combination of DRS and 
frame dropping will probably yield better perceptual results than either technique 
working alone, especially for large rate reductions. 
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4 CONCLUDING REMARKS 

We have presented a novel architecture for supporting video services in a non-QoS 
network, namely the Internet. Several experiments have been performed to verify 
performance in both a controlled environment and in external wide area 
connections in the Internet. Our results show that our proposed architecture 
provides a stable system with good quality video which does not degrade the 
quality of other Internet traffic. 



5 REFERENCES 

Chen, Z., Tan, S. M. Campbell, R. H. and Li Y. (1996) Real Time Video and 
Audio in the World Wide Web, World Wide Web Journal, Vol 1. 

Eleftheriadis, A. and Anastassiou, D. (1995) Constrained and General Dynamic 
Rate Shaping of Compressed Digital Video, Proceedings, 2nd IEEE 
International Conference on Image Processing, Washington, DC, III.396-399. 

Jacobs, S. and Eleftheriadis, A. (1996) Providing Video Services over Networks 
without Quality of Service Guarantees, World Wide Web Consortium 
Workshop on Real-Time Multimedia and the Web, Sophia-Antipolis, France. 

Ortega, A. and Khansari, M. (1995) Rate Control for Video Coding over Variable 
Bit Rate Channels with Applications to Wireless Transmission, Proceedings of 
2nd IEEE International Conference on Image Processing, Washington, DC. 



6 BIOGRAPHY 

Stephen Jacobs received both the B.S. and M.S. in electrical engineering from 
Columbia University in 1994 and 1995, respectively. He also holds a B.A. in 
Physics from Bard College. He is currently a Ph.D. candidate in the Electrical 
Engineering Department at Columbia University and a Graduate Research 
Assistant in the Image and Advanced Television Laboratory. His research interests 
include adaptive multimedia protocols and applications for networks without 
quality of service guarantees. In 1996, Mr. Jacobs was awarded the Kodak 
Fellowship. He is a student member of the IEEE. 

Alexandros Eleftheriadis received the Diploma in EECS from the National 
Technical University of Athens, Greece, in 1990, and the M.S., M.PhiL, and Ph.D. 
degrees in Electrical Engineering from Columbia University, New York, in 1992, 
1994, and 1995 respectively. Since 1995 he has been an Assistant Professor in the 
Department of Electrical Engineering at Columbia University. His research 
interests are in the areas of visual information representation and compression, 
video communication systems, and the fundamentals of compression. Dr. 
Eleftheriadis is a member of the IEEE, ACM, ANSI, and he serves as the Editor of 
the forthcoming MPEG-4 Systems standard (ISO 14496-1). 




PART nVE 



QoS Management 





19 

Integrated CPU and 
Network-I/O QoS Management 
in an Endsystem 

K. Lakshmarij Raj Yavatkar 

Intel Architecture Labs 

2111 N.E 25th Avenue, Hillsboro, OR 97124- 

lakshman @ibeam, intel. com, yavatkar@ibeam. intel, com 

Raphael Finkel 

University of Kentucky, Department of Computer Science 
773 Anderson Hall, Lexington KY 40506, raphael@cs, uky.edu 



Abstract 

Realtime multimedia applications such as conferencing, broadcast video, and 
distributed virtual reality demand predictable QoS from both endsystem and 
network resources. We show how to provide predictable QoS for multimedia 
applications in an environment where applications do not know the exact re- 
source requirements in advance and where both resource requirements and 
resource availability change at runtime. We propose a resource management 
architecture in which applications and the OS cooperate to dynamically adapt 
to variations in the resource requirements and availability. We have imple- 
mented the resulting OS architecture, called AQUA (Adaptive Quality of 
service Architecture), in the Solaris OS, and have used it to manage CPU 
and network-I/0 resources in an integrated fashion. 



Keywords 
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1 INTRODUCTION 

The recent trend in increasing power and versatility of a PC has led to a 
new class of performance-conscious, realtime multimedia applications such 
as audio/video conferencing, broadcast quality presentations, and distributed 
virtual reality. Such applications demand predictable quality of service (QoS) 
from endsystem and network resources. 

In order to provide predictable QoS to such applications in a single-user 
environment, we propose a cooperative model of resource management in 
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which both applications and OS dynamically cooperate to adaptively share 
endsystem resources. 

Our approach is motivated by the following observations about multimedia 
applications and their endsystem environment. 

Resource requirements vary dynamically: The resource requirements of 
variable bit rate applications such as compressed audio/ video players or 
servers cannot be fully determined in advance and tend to vary dramati- 
cally over their life time (Yavatkar & Lakshman 1995). Although a video 
player’s desired rate of execution can be specified in advance, the amount 
of CPU time or bandwidth needed over a time interval may vary dramati- 
cally. Such applications must be able to dynamically renegotiate their QoS 
requirements. 

Resource availability varies dynamically: On an endsystem, resource avail- 
ability dynamically depends on the current mix of applications. For in- 
stance, interactive collaboration applications and distributed games com- 
bine individual multimedia applications that concurrently generate or play 
back multiple audio and video streams. As the resource requirements of in- 
dividual streams change and as applications are started or terminated, the 
amount of available resources for other applications changes. Applications 
must be prepared to dynamically adapt to changes in resource availability. 
Multimedia applications use multiple resources: A typical multimedia ap>- 
plication needs predictable service from more than one resource to achieve 
its desired QoS. A video player must be able to execute periodically and 
obtain the necessary amount of CPU time, memory, bus bandwidth, and 
network bandwidth to successfully receive a video stream, uncompress it, 
and display it. Use of one resource typically leads to an indirect use of an- 
other resource. For example, predictable network-I/0 protocol processing 
requires predictable access to CPU. The OS must include integrated re- 
source management mechanisms that can handle such inter-dependencies. 
Multimedia applications are amenable to graceful adaptation: Unlike 
traditional hard realtime applications, video or audio applications can gen- 
erally adapt to fit within available resources by changing media character- 
istics. For example, a video application can adapt by changing its resource 
requirements across three dimensions: the frame rate {temporal resolution), 
the frame size {spatial resolution), and the pixel depth {visual resolution). 
The relative priority of applications changes dynamically: In a single-user 
environment, the relative importance of one application over another varies 
dynamically. For example, when the user switches from watching a news 
broadcast to a compilation task, the news application may execute at a 
lower priority. Applications should be able to temporarily reduce their re- 
source requirements and switch back to full activity when needed. 

Our thesis is that the resources on an endsystem should be allocated and 
managed adaptively in an integrated manner to accommodate the variations 
in both the QoS requirements and the resource availability. We propose an 
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OS architecture called AQUA (Adaptive Quality of service Architecture) for 
managing resources to provide predictable QoS. 

AQUA uses a cooperative model of resource management; applications (re- 
source consumers) and the OS (the resource provider) cooperate to manage 
resources in the following way. 

When an application starts, it provides a partial QoS specification (for ex- 
ample, a video player wishes to execute 30 times a second, but might not 
specify its compute and bandwidth requirements). The resource provider al- 
locates a resource based on its estimate of the available capacity. 

As the application runs, the resource provider and consumer cooperate to 
estimate the application’s resource requirements and the QoS it receives. As 
resource requirements vary (a scene change alters the CPU requirements of 
a video player) or resource availability changes (other applications start or 
stop), resulting changes to measured QoS are detected, and both the resource 
consumer and provider renegotiate and adapt to ensure predictable service 
within the constraints of available resources. 

We have implemented AQUA in the Solaris 2.4 operating system and eval- 
uated it in an environment consisting of Sun Sparc workstations and a set of 
ATM switches. This paper describes how AQUA manages CPU and network- 
I/O resources. Section 2 provides an overview of resource management. Sec- 
tion 3 describes management of CPU. Section 4 describes integrated resource 
management for providing network-I/0 QoS. Section 5 describes related work. 
Finally, Section 6 summarizes our contributions. 

2 THE AQUA FRAMEWORK 

aqua’s model of resource management assigns an active role to the appli- 
cations in allocating and managing resources. To avoid burdening application 
programmers with the details of QoS negotiation and adaptation and to en- 
courage code reusability, AQUA includes abstract interfaces and libraries that 
hide the details of QoS measurement and negotiation. These interfaces and 
libraries include an application-level QoS manager, a QoS negotiation library, 
and a usage-estimation library. 

A resource specific QoS manager is linked with the application code (Figure 
1). It exports a QoS-specification interface to the application programmer 
and hides the details of negotiation with the resource providers. When an 
application provides a partial QoS specification, the QoS manager handles the 
details of requesting resource allocation from the resource controllers. As the 
application runs, the QoS manager estimates the resource usage and monitors 
the QoS achieved based on the feedback from the resource provider. When 
the measured QoS does not meet the desired QoS (adequate resources are not 
available) or additional resources become available, the QoS manager initiates 
adaptation by invoking an adaptation function supplied by the application. 

Two utility libraries handle common tasks for the QoS manager. The nego- 
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Figure 1 AQUA components: an application-level QOS manager, a resource 
controller for each resource, and libraries for communication between them. 

tiation library hides the details of QoS negotiation with a resource provider. 
The usage-estimation library helps the QoS manager estimate resource usage 
and QoS delivery and includes a resource specific component. It interacts with 
the resource providers and gathers resource-usage and QoS-delivery statistics. 



3 THE CPU RESOURCE 

We will use the CPU resource as an example to describe the details of the 
AQUA framework. We implemented the RAP (Rate-based Adjustable Pri- 
ority) CPU scheduling policy (Yavatkar & Lakshman 1995), which extends 
rate-monotonic scheduling to account for unknown and varying compute times 
and global adaptation across many applications. As shown in Figure 1, CPU 
resource management includes CPU specific components: a CPU QoS man- 
ager, a CPU-specific usage-estimation library component, the CPU resource 
controller (RAP controller), and the CPU scheduler (RAP scheduler in the 
kernel). The RAP controller implements admission control and participates 
in dynamic QoS negotiation with the CPU QoS manager. 



3.1 A Simple Video Server 

Figure 4 shows code for a simple video server that wishes to execute thirty 
times per second to capture, compress, and send video frames. For simplicity, 
we ignore the details of network I/O, which we discuss in a later section. 
Figures 1-3 show the various components of AQUA used by this application. 
The video server executes the following sequence. 

It first invokes the AQUA initialization functions to obtain a handle to 
the CPU resource and starts a CPU QoS manager. It then supplies a partial 
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Turn resource name into unique id 


id.t GetResByNam«(name) 


Request allocation of a resource 
using the given qos parameter 


orror.t GetRes (resid,*qos, 
qos-len) 


ReleEkse the use of a resource 


void RelRes(resid) 


Update resource reservation 
using the given qos 


error.t UpdateQoS (reside 
«qos» qos-len) 


Request notification when 
a resource becomes available. 
The qos parameter contains 
the amount of resource needed 


error.t NotifyQoS(resid, 
*qos»qos.len) 


Register a function for 
handling adaptation requests 


void CBregJldapt(resid» 
(♦funcH), arg) 



Figure 2 Generic resource-negotiation calls provided by the negotiation li- 
brary for resource consumers^ The exact contents of the qos specification is 
resource specific, examples are given in (Lakshman 1997) ^ 



Register resource 
name 


id.t RegName (name ) ; 


Register callback 


void CBbregJlndlrs(id» 


handler functions 


(♦GetRes-func) () , 


for aqua primitives 


(♦RelRes-func) () » 
(eUpdateQoS-func) () » 
(♦NotifyQoS-func) () ) ; 


Request a consumer 


void Adapt Req( id. 


specified by 


*qos. 


id to adapt 


qosUen 


Wait for a response 


id.t AdaptReq-Resp («qos , 


to an adaptation 
request 


qos.len 



Register 
callback 
function to 
monitor 
QoS 


CBregJlonitor(resid, 
(♦funcK), 
caddr.t arg, 
time.t time) 


Get 


GetUsage(resid, 


resource 


4>qos, 


usage 


qos-len) 


Register 


CBreg.Filter (res id , 


filter 


(♦funcK), 


callback 


caddr.t arg) 


function 



Figure 3 A: Calls provided by the negotiation library to allow resource 
controllers and QoS managers to communicate with resource consumers and 
application code. B: Functions provided by the usage-estimation library 

QoS specification containing the desired rate of execution, the averaging in- 
terval for measuring the rate, and an acceptable rate jitter. It cannot specify 
the compute time needed. It registers a function for adaptation (CPU-Adapt), 
which is specific to an application and includes application-specific semantics 
for adaptation. For instance, the video server may first adapt by reducing its 
frame rate followed by a change in its frame size if necessary. It repeatedly 
executes its main body, which is a loop that grabs a frame, packetizes it, and 
sends it. It indicates the end of each iteration by yielding. 

As the video server executes, various components interact as follows. 

1. The video server provides a partial QoS specification, and the QoS manager 
fills in any unspecified QoS parameters that it can determine beforehand 
and invokes the RAP controller for initial resource allocation (GetRes). 

2. The RAP controller scans RAP kernel queues to determine the available 
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Simple Video Server Application 
mainO { 

resid-t cpu; 
rapqos-t ♦qos; 
double rate s 30; 

/* Initialization phase *t 
/♦ get cpu resource identifier ♦/ 
cpu = GetResByName ( * 'CPUQoSHgr ” ) ; 

/♦ Register the callback function ♦/ 

CBreg-Adapt(cpu»CPU .Adapt, NULL) ; 

/* fill in knornn specs */ 
qos s RapQosAlloc(active-adaptive,rate, 
jitter, averaging.interval) ; 

/* Get the resource *! 

GetRes(cpu,qos,rapqoslen) ; 

/♦ Uork phase ♦/ 
while (there is work to do) { 

Do_Vork() ; 

i* tell RAP that me are done 
mith this iteration */ 
aqua.yield(cpu) ; 

} 

/* give up the CPU resource */ , 

RelRes(cpu); 

} 

Figure 4 A AQUA video server. If its resource requirements exceed available 

CPU resource, it adapts by reducing either its rate or its spatial resolution. 

When more resources become available, it adapts by improving video quality. 

CPU capacity {compute time slack). It allocates all available slack (but not 
more than 10 ms on a spare 20) to the new thread. The compute time ac- 
tually used will likely stabilize to a lower value in a few averaging intervals. 

3. The QoS manager monitors the resource usage and QoS received every 
averaging interval via the GetUsage call in the usage-estimation library. 
This library keeps track of the compute time needed per period by collecting 
samples over an averaging interval. When the video server yields at the end 
of each execution period, the usage estimation library accesses kernel data 
structures to learn the amount of compute time used in that iteration. It 
then calls a low-pass filter in the QoS manager to compute a long-term 
average. It also records the observed rate of execution. 

4. The QoS manager uses the UpdateQoS call to update the RAP controller’s 
initial estimate of the compute time by giving it the filtered compute-time 
requirement. The RAP controller now has a reliable estimate of the com- 
pute time used; so it can add excess unused capacity to the slack estimate. 

5. If the QoS manager observes a change in CPU usage, it updates its reser- 
vation with the RAP controller (UpdateQoS). 

6. The QoS manager compares the QoS delivered with the requested QoS. If 
the delivered level of QoS is less than that requested, the QoS manager 
requests an increased allocation of compute time from the RAP controller. 
If the RAP controller is unable to meet the new requirements, the QoS 
manager asks the video player to change its behavior by invoking the video 
player’s adaptation function (AdaptReq). 

7. When several applications compete for CPU and adequate aggregate ca- 



Application Adaptation Function 
int CPU Jldapt (resid-t cpu, rapqos.t *qos, 
action what) { 

/* use hint provided by CPU QoS manager 
in QoS struct for new values ♦/ 
switch (what) { 
case DEGRADE: 

reduce-ny jrate.or jresolut i on 
retum(-l) ; 
case UPGRADE: 

additional capacity available 
inc reas e - V ide 0 .qual i t y ; 
return (0) ; 

} 

} 
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pacity is not available, the RAP controller may resort to global adaptation 
either by reducing the resource allocation of each admitted application 
(transparent adaptation) or by explicitly requesting that each application 
reduce its resource requirements (active adaptation) (AdaptReq). 



4 INTEGRATED CPU AND NETW0RK4/0 MANAGEMENT 

Actual applications typically need more than just the CPU resource. For ex- 
ample, a video server needs predictable QoS from both CPU and network-I/0 
resources. Network I/O indirectly requires other resources, such as CPU for 
protocol processing, I/O-bus bandwidth for transferring data between mem- 
ory and network-I/0 devices, and the network interface for transmitting data. 

The AQUA framework integrates resource management for CPU and network- 
I/0 resources. Integrated resource management is achieved by using a compos- 
ite QoS manager that uses the services of both the network-I/0 QoS manager 
and the CPU QoS manager. The application specifies its QoS requirements to 
the composite QoS manager. Each QoS manager is responsible for determin- 
ing the application’s requirements for its resource. The QoS managers interact 
with their corresponding resource controllers to negotiate the QoS. 

The network-I/0 provider consists of a network-I/0 controller, responsible 
for admission control and global adaptation, and the network-interface driver, 
which controls link scheduling. 

In the following, we describe our implementation of an integrated resource 
manager that provides predictable QoS for network data transfer by managing 
both CPU and network I/O subsystems in the Solaris OS. Although data 
transfer uses bus bandwidth, we have not yet implemented a bus-bandwidth 
management component of the integrated resource manager. 

To ensure that the interrupt and protocol processing is done in a timely 
fashion in the OS, we addressed three problems that arise in the Solaris OS: 
(1) When many processes concurrently transfer data streams across the pro- 
tocol stack, each data transfer affects the predictibility of other data transfers 
(the inter-stream interference problem). (2) When a process requests an I/O 
operation such as reading a block of data, the I/O is performed in the back- 
ground using asynchronous, interrupt-driven I/O. When an I/O interrupt oc- 
curs, the currently executing process is interrupted and delayed, which makes 
its execution unpredictable (the I/O interference problem). (3) To allocate 
and account for the CPU time used for protocol processing, the QoS manager 
must be able to estimate the CPU requirements of protocol processing. 

Figure 5 illustrates the impact of these problems. Process 1 is a realtime 
application that sends data over the ATM network. It competes with process 
2, a nonrealtime application that sends data over a 100 Mbps ethernet. After 
process 2 starts at time 30, process 1 is unable to receive the QoS it requires 
(send-data rate of 40 Mbps). After about 10 seconds, the QoS manager in 
process 1 first reacts to the delivered QoS by asking for more compute time and 




178 



Part Five QoS Management 



successfully adapts to the interference because the additional CPU capacity 
is available. Figure 6 shows the same scanario, but now process 2 uses a larger 
send-block size (640 KB). When the QoS manager in process 1 tries to adapt 
by requesting more compute time, it fails because sufficient CPU capacity is 
not available to accommodate the request. 

The I/O interference visible in Figures 5 and 6 is due both to the overhead 
of TCP-ACK processing and to the fact that the streams scheduler fails to 
insulate the realtime ATM stream from the non-realtime TCP stream. In So- 
laris, processing an incoming packet involves preempting the current thread 
and running an internal kernel interrupt thread. The TCP input function is 
called in the interrupt context. TCP protocol processing occurs in the in- 
terrupt routine when an ACK is received. The increase in compute time of 
process 1 is an artifact of attributing the time used by interrupt and ACK 
processing for process 2 to process Ts account whenever it is interrupted. 

One solution is to fix the accounting error to ensure that interrupt-processing 
time is not added to the compute time of interrupted threads. However, the 
interrupted realtime application can still miss its execution deadlines because 
its execution is delayed by the higher priority interrupt processing. 

Instead of processing the incoming packet completely during an interrupt, 
we have introduced a new streams function called putschednext (shown in 
Figure 7) that postpones the protocol processing when an interrupt occurs. 
The IP streams module usually uses the putnext routine to pass data on to 
the TCP streams module. The new putschednext function, which is tied in 
with the RAP scheduler, replaces the putnext function in the TCP processing 
path. When invoked, it checks to see whether the interrupted thread is in the 
RAP class. If so, putschednext discontinues processing the packet and hands 
it to a background handler thread. Otherwise, it avoids the context switch 
and continues handling the packet itself. 

We have observed that the streams scheduler uses a FCFS discipline. Before 
sending out the data for the ATM application, it processes buffered incoming 
data that was meant for processing by the streams background handler thread. 
It also first processes previously buffered outgoing data belonging to other 
I/O streams. The cost of processing such data is then charged to the ATM 
application. This FCFS nature results in processing TCP data in the context 
of the ATM application and causes interference with realtime data processing. 

In AQUA, we have introduced a general purpose mechanism to solve the 
I/O interference problem and the problem of estimating CPU time needed 
for I/O. Our solution for the output (send) side extends the current Solaris 
implementation to make it sensitive to QoS needs of individual streams. An 
application indicates that a given stream is realtime by invoking a new ioctl 
option. A modified streams scheduler uses this information to shepherd the 
outgoing data through the protocol stack without any delay or buffering. It 
ensures that outgoing data for non-realtime streams is not processed first 
when processing data for a realtime stream. 
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Figure 5 Successful QoS adaptation. Process 1 sends packets of size of 4 KB 
at a rate of 40 Mbps at an execution rate of 50 times/sec, consuming 8 ms 
per period. Process 2 starts at time 30, sends data with a TCP window size 
of 32 KB and a send-block size of 32 KB. 
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Figure 6 Unsuccessful QoS adaptation. The processes are the same as in 
Figure 5, but process 2 sends data in 640 KB blocks. 
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Figure 7 A (original) The IP streams module uses the putnext function to 
pass data on to either TCP or UDP streams modules. B (putschednext) To 
to provide better predictability, the IP streams module uses putschednext 
to pass data on to the TCP streams module C (AQUA sensitive send- 
path) A new ioctl call allows creation of realtime streams; the modified 
streams scheduler only processes data belonging to a process that initiated 
the send. D ( AQUA-sensitive receive path) Early demultiplexing by the 
device is necessary to ensure proper QoS. Incoming data is processed when 
the application issues a read call. 

So far, we have only implemented the send side of this solution, but the 
receive side of protocol processing can also be made sensitive to QoS needs 
of realtime streams by generalizing the putschednext function. The network- 
interface driver or the network card should be capable of determining the 
destination process for incoming data. An incoming packet is queued up in 
the lowermost module of a stream until the recipient process issues the read 
system call. This call allows RAP to perform protocol processing in the context 
of the recipient process and to charge the compute time appropriately. A 
similar solution for input part of protocol processing has been implemented 
in (Druschel & Banga 1996) to improve protocol processing efficiency. 

These modifications ensure that protocol processing costs are charged ap- 
propriately to the application that performs I/O and that data is transferred 
according to the realtime nature of the application. The cost of interrupt 
processing itself can still interfere with an application and needs more study. 

To demonstrate the effect of our modifications, we repeated the experiments 
involving an ATM-based application and the TCP-send application. Figure 8 
shows the effect of using the AQUA sensitive send path and putschednext on 
the ATM send-data rate when an interfering TCP application is also present. 
The interference is significantly reduced compared to Figure 6. 

5 RELATED WORK 

Govindan and Anderson (Ramesh Govindan 1992) proposed a new schedul- 
ing mechanism consisting of a split-level realtime scheduler based on the EDF 
(Earliest Deadline First) discipline. The authors were first to point out the 
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Figure 8 Same as in Figure 6, but process 1 declares its stream realtime via 
an ioctl call; the IP module uses the putschednext function for TCP data. 



need for applications to accurately (and apriori) estimate their resource re- 
quirements. AQUA, in constrast, includes mechanisms to dynamically esti- 
mate the resource requirements of applications. 

Under the Q-thread (Kawachiya & Tokuda 1996) execution model, applica- 
tions can specify a rate of execution, determine the amount of compute time 
available at that rate, and adapt to that compute time. The form of adap- 
tation supported is similar to the AQUA’s transparent adaptation model. 
Applications specify the adaptation policy to a QoS server, which initiates 
degradation. 

OMEGA (Nahrstedt & Smith 1995) supports end-to-end QoS management. 
QoS negotiation is performed by a QoS broker. The application-level QoS 
manager in AQUA is similar to the QoS broker; the AQUA negotiation library 
uses a protocol that is similar to the QoS-broker negotiation protocol. 

An architecture for endsystem QoS, which is composed of components for 
specifying, mapping, and enforcing QoS has been developed in (Gopalakrishnan 
& Parulkar 1994). An application specifies high-level QoS requirements based 
on predefined profiles. The framework maps these profiles into QoS specifica- 
tions for all the resources used by the application. Applications make use of 
a realtime upcall to ensure CPU and network-I/0 QoS. 

Coulson et ai present the design of a QoS-controlled communications re- 
source (Coulson, Campbell, Robin, Blair, Papathomous & Shepard 1995). 
Their design provides an API for applications to specify QoS, proposes ad- 
mission control tests for various classes of network traffic and explores methods 
to translate network-QoS requirements into CPU and memory requirements. 
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6 CONCLUSIONS 

We have demonstrated a way to provide predictable QoS for multimedia appli- 
cations in an environment where applications do not know the exact resource 
requirements and both resource requirements and resource availability vary 
dynamically. AQUA presents a cooperative model of resource management. 

To use the CPU resource, an application only specifies the required rate 
of execution, and an application-level CPU QoS manager dynamically esti- 
mates compute-time requirements. The CPU QoS manager reacts to resource- 
requirement and availability changes to insulate applications from full QoS 
specification and negotiation. 

We have explored integrated management of a composite resource like I/O, 
which consists of CPU, network-interface bandwidth, and bus bandwidth. 
The I/O-interference and inter-stream interference problems in Solaris streams 
highlight the problems inherent in existing I/O-resource implementation. Our 
extensions to the Solaris streams make the data paths sensitive to the QoS 
needs of applications. We ensure that data is transferred across the proto- 
col stack taking into account realtime requirements while charging protocol- 
processing costs to the corresponding application, and allowing a QoS manager 
to estimate the CPU needs for network-I/0. 
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Abstract 

Service integrated communication systems need to serve concurrently a vari- 
ety of applications, probably each of them with different service requirements. 
Therefore, an integrated Quality-of-Service (QoS) management is needed. 
Within this paper, a flexible approach of QoS management in high perfor- 
mance networks is presented. QoS management functions can be configured 
in order to build a service-tailored management. Moreover, performance mea- 
surements of the presented management functions are discussed. 



1 INTRODUCTION 

Service integrated communication systems need to provide concurrent sup- 
port for an increasing variety of applications. Typically, such applications 
communicate simultaneously via several data streams, including audio, video, 
and conventional data traffic. Each stream is characterized by highly differ- 
ent service requirements commonly expressed in terms of so-called quality of 
service parameters (QoS parameters). Most importantly, these applications 
require QoS guarantees from application-to- application. Thus, an integrated 
QoS management is necessary, covering all management functions in end and 
intermediate systems. 

As an integral part of a communication system, certain mechanisms (e.g., 
scheduling, protocol functions) are needed to support service requirements. 
Typically, basic QoS guarantees can be given for resources by an adequate 
resource management (Nahrstedt & Steinmetz 1995). QoS guarantees pro- 
vided by a resource management solely are not sufficient for applications. 
Especially, for coordination and enhancement of basic guarantees from re- 
source managers, integrated QoS management functions are highly needed 
(Hutchison et al. 1994). Integrated QoS management is concerned with an 
enhanced application-oriented QoS specification, QoS mapping, QoS negotia- 
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tion, QoS maintenance and QoS control (configuration and monitoring). Thus, 
QoS management architectures (Campbell et al. 1996) for an integrated QoS 
management must support a QoS-based API at which applications are capa- 
ble to specify their service requirements in an application-oriented syntax and 
semantics. 

Several aspects have to be considered while designing and realizing an inte- 
grated QoS architecture and its management functions. First, QoS manage- 
ment functions running complex tasks needed by a certain service specification 
must be able to keep up with the high data rates of networks, such as ATM. 
Second, management functions, such as QoS negotiation and QoS monitor- 
ing, have different time requirements (Campbell et al. 1996) and thus, have to 
be separated according to their time domains. It is crucial, that management 
functions with stringent time bounds are capable to operate autonomously and 
in parallel to functions with less severe time requirements. Finally, applications 
demand very different service support. Therefore, besides configuration of ser- 
vice supporting mechanisms, configuration of management functions based on 
the service specification plays an important role. Only a service-tailored QoS 
management is able to meet the varying demands of forthcoming applications. 

This paper presents an approach towards a highly flexible and service- 
tailored QoS architecture for high performance networks. In section 2, the 
COSIMA architecture for integrated QoS management is introduced in some 
detail. Section 3 presents the QoS-Manager, a central component of the COSI- 
MA architecture. First, tasks of the QoS-Manager and its architecture are 
described. In a next step, the implementation and performance results are 
presented. Afterwards, in section 4 another component of the architecture, a 
flexible QoS Monitor is introduced. Flexibility of the QoS Monitor and per- 
formance measurements are discussed. Finally, the paper is concluded by a 
summary and a description of future work. 



2 COSIMA - A QOS MANAGEMENT ARCHITECTURE 

The COSIMA-Architecture (COmmimication Systems with Integrated ser- 
vices MAnagement) represents a QoS management architecture that strictly 
separates resource and integrated QoS management functions. The data path 
is represented by a sequence of resources, each of them managed by a resource 
manager. QoS management functions are used to coordinate and enhance the 
underlying resource management in order to provide an integrated manage- 
ment requested by applications. All management functions are stringently 
separated from data transfer and are located in the management architecture 
as shown in Figure 1. However, this architecture is not derived from hierarchi- 
cal layered communication systems, but from the functionality of management 
tasks. 

The overall behavior of the management system is presented to applications 
at a high-level application interface, where applications are capable to specify 
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Figure 1 COSIMA: QoS Management Architecture 



their communication needs in an application-oriented syntax and semantics. 
They communicate with a so-called QoS-Manager that coordinates all opera- 
tions of the underlying management. At the COSIMA Application Program- 
ming Interface (API), applications are able to request and modify communi- 
cation services for sessions and data streams (Prick & Schmidt 1996). A data 
stream is a simplex point-to-point or multi-point connection between appli- 
cations associated with a certain quality-of-service. Several data streams be- 
tween two or more distributed applications and relations among these streams 
are grouped into a session. 

Communication resources are grouped into three areas and are managed by 
one control entity in each area. COSIMA comprises control entities for net- 
work^ operating system, and communications subsystem (Schmidt & Zitterbart 
1995). Each control entity consists of a control agent and a QoS monitor. 
The control agent is responsible for configuration and reconfiguration of re- 
sources and resource managers and the QoS monitor continuously monitors 
the achieved QoS. Management-related information of each resource manager 
and managed resources is presented to the corresponding control entity by 
so-called resource objects. Examples of such information are resource capac- 
ity, control mechanisms for resource management (e.g., scheduling algorithms) 
and information about data streams that currently use the resource. All com- 
munication between control entities and resource managers is done through 
resource objects, and thus a clearly defined service interface exists. Since re- 
sources as well as resource managers are operating in the data path, they are 
very time critical. Therefore, based on resource objects they are clearly decou- 
pled from control operations performed by control agent and QoS monitor. 
However, control functions must be able to keep up with high data transfer 
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rates and therefore, both components of a control entity are designed for high 
performance environments. 

In order to supply integrated services, the COSIMA-Architecture needs an 
entity that coordinates the cooperation of its autonomous area management 
components. This entity is the QoS-Manager, As a central integrating compo- 
nent of the communication system the QoS-Manager has to manage exchange 
of service control information with all applications that use integrated com- 
munication services in the local end-system. To provide integrated communi- 
cation services from application-to-application it distributes QoS management 
information among local components and other QoS-Managers at remote end- 
systems. 

3 THE QOS-MANAGER 

Generally, tasks of the QoS-Manager can be coarsely divided into following 
functional areas: 

• Communication with applications using an application-oriented service in- 
terface. 

• Distribution of information about the session (locally as well as to re- 
mote end-systems). This especially includes negotiation and renegotiation 
of QoS. 

• Adaptation of information between different levels of service specification 
(i.e. QoS-Mapping). 

The QoS-Manager supplies access to integrated services of the communication 
system by offering an application-oriented service interface. Thus, applications 
express their communication requirements in an application-oriented syntax 
and semantics by using so-called data stream objects. A list of data stream 
objects together with a list of relation objects constitute a session object. A 
relation object describes a logical or temporal relationship between a pair of 
data streams. Examples of logical relationships are lifetime-relation (existence 
of one data stream is required by another), identical participants or identi- 
cal QoS. The temporal relation specifies synchronization conditions between 
data stream by use of a skew-interval (Blakowski & Steinmetz 1996). In order 
to provide a very flexible but still easy-to-use service interface, applications 
can select among predefined session and data stream types, individually com- 
posed sessions or even single data stream specifications. Applications control a 
certain session by invoking service primitives as methods on the associated ses- 
sion object (e.g., OpenReq, Nodif yAddRsp). There exist service primitives for 
opening a session, changing a session by modifying the characteristics of data 
streams, deleting or adding data streams, joining or leaving a session, notifi- 
cations and closing a session. By use of management parameters for each data 
stream, such as priority, report policy, action policy, and cost, applications 
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are able to direct management behavior in their intended way. The degree 
of autonomous QoS management actions is determined by the action policy. 
Additionally, a report policy determines the amount of information flowing 
from QoS-Manager to application. Hence, each application can choose its pre- 
ferred management behavior. Because the QoS-Manager is only concerned 
with management and control of communication services it is not involved in 
actual data transfer. Thus, its operation is not really time critical, but it must 
be able to process several requests from different applications simultaneously. 
This is necessary because there exists only one QoS-Manager entity in an end- 
system, and communication with one application should not suspend other 
applications from using integrated communication services. Consequently, the 
QoS-Manager uses asynchronous message exchange for communication with 
applications and holds state information for each application. 

During establishment of a session its properties are negotiated in terms of 
QoS parameters among all participants. In the course of an active session 
dynamical changes can occur such as renegotiation of a data stream’s QoS 
parameters, joining or leaving participants and addition or removal of data 
streams. Additionally, monitoring information or reports about QoS violations 
can be exchanged. In the COSIMA- Architecture, end-to-end communication 
between QoS-Managers of session participants is accomplished by use of a QoS 
Management Protocol (QMP), whereas local communication between QoS- 
Manager and system components is determined by a Local Communication 
Protocol (LCP). The latter is necessary, because control entities of the areas 
network, operating system and communication subsystem are involved in the 
negotiation process. Furthermore, for negotiation of resources in intermediate 
and end-systems at network level a common network reservation protocol such 
as RSVP (Zhang et al. 1993) or ST2-f (IETF 1995) is used. 

On one hand the QoS-Manager uses application-oriented QoS parameters 
at the service interface (e.g., frame size, frame rate and color depth of a video 
data stream), but on the other hand it communicates with control entities in 
system-oriented QoS parameters (e.g., throughput, delay, loss rate, etc.). Both 
representations of a data stream must be mapped onto each other (system- 
oriented parameters cannot be always mapped uniquely onto application pa- 
rameters). To reduce the need for further mapping operations, all compo- 
nents of the COSIMA- Architecture operate only on application-oriented and 
system-oriented parameters. 



3.1 QoS-Manager architecture 

The architecture of the QoS-Manager depicted in Figure 2 is derived from the 
required functionality described above. Therefore, the QoS-Manager is divided 
internally into three parts reflecting its functional separation: The coordina- 
tor part controls the sequence of events within the QoS-Manager and handles 
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communication with applications. It manages all session-related information 
and operates on subsets of the session’s data streams or the whole session. 
All negotiation tasks and other information exchange with local components 
as well as remote systems are managed by the communicator part. The Com- 
municator negotiates complete sessions (including several data streams) at 
once and is even capable of managing many different negotiations in parallel. 
Processing different primitives on several data streams for one session and 
various sessions simultaneously is possible, too. This leads to faster response 
times because waiting for responses belonging to one negotiation does not sus- 
pend the course of other negotiations. Coordinator and Communicator oper- 
ate extensively independent and mutually exchange messages to interchange 
information, i.e. they are active entities (specified as enhanced finite state 
machines). Additionally, the QoS-Manager contains a library of QoS mapping 
functions (a so-called QoS-Mapper) in order to map application-oriented QoS 
parameters onto system-oriented QoS parameters and vice versa. In contrast 
to Communicator and Coordinator the QoS-Mapper is a passive entity. Fur- 
thermore, QoS specifications of data streams and other management related 
data is stored in a database called Internal QoS Structure (IQS). 




Figure 2 The QoS-Manager 
3.2 QoS Negotiation 

As mentioned above, a specific protocol was defined for end-to-end commu- 
nication: the QoS Management Protocol (QMP). It was designed from the 
beginning for eflScient support of arbitrary group communication scenarios. 
By distinguishing only the roles of initiator and responder of negotiation or 
management requests it is independent of the directions of data flows. This 
concept similar to the QoS-Broker (Nahrstedt & Smith 1995) yields more 
flexibility and opens up the complete multitude of application scenarios. Ad- 
ditionally, it is possible to negotiate several data streams at once, thus re- 
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ducing necessary negotiation steps and session setup delay. By negotiating 
several streams simultaneously end-to-end delay has to be considered only 
once, whereas other negotiation protocols execute end-to-end negotiation for 
each stream separately. The latter results in an n-times higher end-to-end de- 
lay for n streams and insufficient support for group communication scenarios. 
Moreover, if streams are negotiated singly and the last stream in such a ne- 
gotiation process becomes rejected all previous negotiation steps would have 
been of no avail. Furthermore, sender- or receiver-oriented reservation proto- 
cols can be used to request resources at network level if those mechanisms are 
not already embedded into the network itself. 

To outline the features of QMP a brief description of a QoS negotiation 
process is given. It is needed for session opening, when a new participant is 
going to join a current session, and when data streams are added or their 
parameters are changed. The negotiation process can be executed for all data 
streams simultaneously and is coarsely divided into four steps: at first the 
initiator carries out negotiation with its local components (operating system, 
communication subsystem, and network). In the second step an end-to-end 
negotiation with the involved remote end-systems follows, that perform a local 
negotiation on their part and inform the initiator about the results. The latter 
tries to find a consensus out of the different responses and sends it back to 
the responders. The third step consists of resource reservation within the net- 
work by using a network reservation protocol. Corresponding to the selected 
reservation protocol each end-system requests resources for either incoming or 
outgoing data streams and awaits results from this reservation procedure. Af- 
terwards, every system has got the same view of committed network resources. 
Finally, the application-oriented parameters have to be adapted according to 
negotiated network parameters in the fourth step using a ^backward’ mapping 
function for QoS parameters (Schmidt 1997). This step is completed by releas- 
ing over-allocated resources (‘relaxing’) locally and within the network. The 
latter follows from the fact that most application-oriented parameters can- 
not be continuously mapped onto network parameters, so formerly negotiated 
network parameters have to be possibly rounded-off again. Subsequently, the 
application is notified about the negotiated QoS. This particular sequence 
of negotiation steps was chosen because no unnecessary reservation of net- 
work resources is done when local resources are short or essential application 
parameters are not supported by the other peers. 



3.3 Implementation and Performance 

The QoS-Manager was implemented in C-f-f on Alpha- Workstations under 
Digital Unix 3.2 which is based on a Mach kernel. By using an object-oriented 
language it is easily possible to enhance the existing class hierarchy of streams. 
Common attributes of all streams form an abstract base class from which spe- 
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cialized stream classes (e.g., audio, video) are derived. The QoS-Manager is 
an autonomously running entity (process) that communicates with all ap- 
plications using integrated communication services. Inside the QoS-Manager, 
Coordinator and Communicator are realized as separate threads which use 
Mach facilities for interchanging messages. By using threads a high possible 
degree of parallel processing at a small overhead is reached. This results in 
shorter response times during multiple simultaneous negotiations. 




Figure 3 Internal processing times of QoS-Manager for negotiation 

Performance of the QoS-Manager was measured by using the thread jLnfo ( ) 
Mach-Kernel call (Boykin et al. 1993). It returns among other things the time 
a particular thread spent in user space. Results for a QoS negotiation process 
are depicted in Figure 3. The measured times do not include activities of other 
components like control entities or network resource reservation entities. Mea- 
surements were executed by opening sessions consisting of 1, 2, 5, 7 and 10 
data streams. Every scenario contained 200 measurements. The highest value 
(14.1 ms) was measured at the responder side for a session consisting of 10 
data streams. Conditioned by the increasing amount of specification data, ne- 
gotiation time grows linear with number of data streams. But, in spite of the 
additional complexity it is only growing linear, not more. However, a complete 
QoS negotiation in one end-system will last some milliseconds. Naturally, the 
required end-to-end delay as well as response times of all involved entities have 
to be added in order to complete one negotiation. But one can expect that 
those response times are considerably smaller than actual end-to-end delays. 



4 QOS MONITORING 

In this section another QoS management function located closer to the data 
path is addressed. QoS monitoring continuously determines QoS parameters 
from protocol information. Additionally, QoS violations are detected by a 
comparison of measured parameters with parameters negotiated in the traffic 
contract. A fiexible and service-tailored QoS monitor has to monitor efficiently 
service requirements of a variety of forthcoming applications and, further- 
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more, it must be able to work besides different communications protocols on 
transport and network level. Therefore, a configurable QoS monitor is needed 
whereas high performance communications require a small monitor with little 
overhead. 

Based on the architecture and specification in (Schmidt & Bless 1996) 
the presented QoS Monitor entity was extended with configurable interfaces. 
These comprehend two different components: initial protocol-dependent QoS 
configuration, and, flexible and dynamic configuration per connection. The 
initial protocol-dependent QoS configuration adapts the QoS Monitor to QoS 
parameters supplied by different communication protocols. Controlled by the 
accompanying control agent (see section 2) the flexible and dynamic configu- 
ration per connection allows to vary the set of parameters to be monitored and 
to change the report behavior of the QoS Monitor dynamically during opera- 
tion. Implementing these design issues means to be careful with performance 
behavior of the monitor because monitoring of real-time systems has got very 
sensitive time constraints. Therefore, the following performance evaluation is 
an essential matter of this section. 

4.1 Performance Evaluation 

For evaluation of the achievable performance a test network consisting of 
two Alpha workstations (AXP 3000/500) and a DEC GIGAswitch was used. 
The protocol stack is based on a test protocol over UDP/IP and AAL5 over 
a 155 Mbit/s ATM link. The test protocol adds a small header with fields 
for packet type, time-stamp, and sequence number to user data. Considering 
protocol overhead, maximum achievable throughput within the test protocol 
is about 135 Mbit/s (Schmidt 1997). 

Examining the performance issues consists of two parts: first, influences of 
high data rates on the QoS Monitor, and second, overhead entailed by the QoS 
Monitor. The first topic addresses performance of the QoS Monitor in high 
performance networks. In these environments, the QoS Monitor must be able 
to keep up with communication speed without any performance influence on 
the protocol. Throughput was measured for a varying size from 256 to 8192 
Bytes of user data units (cf. Figure 4(a)). For each size, average (over 100 
events) and maximum throughput were determined in 1000 measurements. 
While the measured maximum throughput for small data units was only about 
15 Mbit/s, large data units yielded throughput values over 134 Mbit/s. Thus, 
transmitting large data units leads to throughput values near to the theoretical 
achievable throughput. In contrast, throughput reduction for small data units 
is based on the high amount of packet processing time compared to the small 
amount of data. But generally, the QoS Monitor was able to keep up with all 
data rates and to determine all QoS parameters in time. 

Measuring monitor overhead was the next step. Again, 1000 measurements 
were performed for each configuration. Statistical monitoring is based on an 




192 



Part Five QoS Management 




4096 em 

s» ol j»rdala 



IhrCuOTipuT Ot 

+ dflfcsv 4 import *d 

^t!er ponorroTmi 



(a) Receiver throughput for various 
user data packet sizes 
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Figure 4 QoS Monitor performance 



interval of 100 measurement points in which 10 QoS violations are allowed. To 
achieve a comparable value for variations of different configurations two dis- 
tinct test configurations have been applied: monitoring of different parameter 
combinations, and, comparison between deterministic and statistical moni- 
toring. Because the QoS Monitor is implemented by using threads (Schmidt 
& Bless 1996), too, the thread_info() Mach-Kernel call was applied here 
also (cf. section 3.3). Figure 4(b) shows a comparison of the monitor overhead 
for different parameter configurations. Generally, determination of one QoS 
parameter and a test for QoS violation needs about 10/is. Therein, a basic 
overhead of around 4/jls is produced by internal copy and loop operations 
within each monitoring step. The comparison between deterministic and sta- 
tistical monitoring shows an additional overhead of 2-3/iS per parameter for 
statistical monitoring. 

Comparing these results with performance measurements of communica- 
tion protocols in user space (Braun & Diot 1996) shows a monitor overhead 
lower than 10% of the protocol overhead. But, while protocol processing time 
grows with the size of data units, the measured monitoring time is totally 
independent of data unit sizes. 

The presented performance results reflect directly the flexibility of the QoS 
Monitor. It can be configured in order to monitor one or more selected QoS pa- 
rameters for a connection. Additionally, the flexible protocol interface allows 
monitoring in changing environments. These characteristics and the results 
of the performance evaluation show that the developed QoS monitor is flex- 
ible and can be tailored to the requested service while operating under high 
performance conditions. 

Comparing performance results of QoS-Manager and QoS Monitor shows, 
that both components operate on different time scales. Typical operating 
times of the QoS Monitor are located in the range of jjls while the QoS- 
Manager operates in ms. These operating times confirm directly the design 
decisions of the COSIMA architecture. It is crucial that management compo- 
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nents operating on different time scales are located in autonomous entities. 
Thus, time critical components, such as the QoS Monitor are able to work 
autonomously and are not influenced by complex management tasks of other 
components. 



5 SUMMARY AND FUTURE WORK 

Generally, integrated QoS management forms an increasingly important com- 
ponent of service integrated communication systems. The presented QoS man- 
agement architecture COSIMA provides integrated services from application- 
to-application. Derived from the functionality of management tasks it consists 
of autonomous entities that are coordinated by a QoS-Manager. The latter 
supplies an application-oriented service interface to applications and conflg- 
ures the functionality of system components appropriately. Furthermore, it 
uses flexible and comprehensive mechanisms for distributing QoS manage- 
ment information, including QoS negotiation and renegotiation. The QoS- 
Monitor for the communication subsystem was presented as an example of 
a management component located closer to the data path. It is flexible ac- 
cording to monitored QoS parameters, thereby leading to a reduced overhead. 
Finally, comparison of performance measurements for QoS-Monitor and QoS- 
Manager confirm the separation of management functions with different time 
constraints into autonomous components. 

The cooperation with RSVP as network reservation protocol is planned 
next. Moreover, management strategies of the QoS-Manager have to be ex- 
amined and tested in several scenarios. This especially includes heterogeneous 
scenarios where session participants have very different capabilities to support 
QoS. However, the achieved results show the general practicability of QoS 
management systems for high performance networks. 
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Abstract 

We developed a new QoS management scheme called Cooperative QoS man- 
agement which is especailly suitable for multicast multimedia communication. 
In this paper, we discuss how this new scheme influences the design of appli- 
cations based on it. 



Keywords 

QoS management, MM application design, multicast 



1 INTRODUCTION 

In multimedia applications including multicasting to many users, such as 
teleconferencing or educational applications, the QoS management approach 
where QoS levels are negotiated between sender and receiver is not workable 
anymore, because the number of users involved is too large. For instance, ne- 
gotiation of QoS parameters between the sender and every single receiver be- 
comes impossible, since (1) the system would quickly become overloaded and 
(2) it would have to take into account (and possibly provide) many different 
qualities requested by users. Instead, a more decentralized approach seems 
suitable, where QoS management functions such as QoS negotiation, adapta- 
tion or renegotiation are distributed over the network. We developed such an 
approach called Cooperative QoS Management (Fischer, Hafld, v. Bochmann 
and de Meer 1997), where so-called QoS agents are installed on the routers 
and end systems participating in an applications. 

After a brief introduction into the principles of Cooperative QoS Manage- 
ment in Section 2, this paper gives, in Section 3, some hints how the design of 
applications is affected when based on this new scheme, using a teleteaching 



Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
© 1997 IFIP. Published by Chapman & Hall 




196 



Part Five QoS Management 



application as an example. An extended version of the paper is available as 
technical report from the authors. 



2 COOPERATIVE QOS MANAGEMENT 

Cooperative QoS Management has been developed with multimedia applica- 
tions in mind, in which many users participate at the same time, such as 
teleeducation systems or life video transmissions of major sports events. We 
assume that single data streams are multicast to many users and that senders 
offer the same media stream in several qualities, e.g. a high, a medium and a 
low quality video stream. There are no individual QoS negotiations between 
senders and receivers; rather, receivers have to select among the qualities 
offered by the senders. However, QoS negotiations are carried out between 
receivers and QoS agents which are installed throughout the system. This 
makes up a major difference of our approach to a similar one discussed for the 
MBone (McCanne, Jacobson and Vetterli 1996), where no negotiations take 
place at all. 

The QoS agents are able to communicate with their neighboring agents, in- 
forming them e.g. about current QoS values supported in their local area 
or about possible QoS problems. This knowledge is basically application- 
oriented, i.e. the agents know about QoS requirements and negotiated values 
for users as well as relationships between streams. This constitutes a main 
difference of our approach compared to existing QoS management functions 
on network nodes which deal with lower-layer QoS, such as ATM cell loss 
priority etc., and which do not have any information about relations between 
streams and applications. 

Inter-agent communication facilitates inter-agent cooperation the goal of 
which is to provide the QoS levels requested by the application. An interest- 
ing new feature, compared to other QoS management schemes, which becomes 
possible due to this decentralized approach, is the possibility of communica- 
tion between users resp. their local QoS agents, allowing for a cooperative 
selection of desired qualities. If users cooperate and decide to request a ser- 
vice in the same quality, less resources have to be reserved, which in turn 
leads to lower communication costs and higher resource availability for other 
applications. Details on our scheme can be found in (Fischer et al. 1997). 



3 APPLICATION DESIGN 

In (Hafid and von Bochmann 1997), we developed a framework for QoS man- 
agement in the context of presentational multimedia applications. The multi- 
cast nature of many conversational applications, the participation of a huge 
number of users and the use of Cooperative QoS Management calls for a 
revision of this framework. We identified a number of major changes which 
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mainly affect two application components: a user- visible part, namely the QoS 
interface, and an invisible part, namely the QoS agent. 

• QoS user interface 

In our framework for presentational multimedia applications, users resp. 
QoS managers do not have the information on all existing multimedia doc- 
ument variants, and they access documents in individual sessions. The QoS 
user interface was then designed to give users the ability to specify the de- 
sired quality of service for each media type (audio, video, etc.) and thus 
to limit the number of document variants to be checked and offered by 
the QoS manager. As we already pointed out at the beginning, we believe 
that in multicast applications, only a limited number of qualities should 
be offered for a given media type. Using Coop. QoS Management, the in- 
formation about all available media types and qualities is available from 
the network QoS agents. Thus, we do not ask the user to specify his re- 
quirements is advance, but offer him all available qualities for the session 
components. He then simply selects the ones desired. 

• QoS agent 

Our QoS manager in presentational multimedia applications goes through 
several consecutive operations to implement the negotiation process be- 
tween a client and a server. This process involves different interactions 
between the QoS manager and the user on one hand, and the QoS man- 
ager and the remote service providers on the other. When the number of 
users becomes large, as in our teleteaching application, this process be- 
comes too heavy for the whole system, since every single component would 
be in steady negotiation processes with new users. Due to the multicast 
nature of the application and the characteristics of Cooperative QoS Man- 
agement, however, the design of the QoS manager can be simplified by far. 
If a certain stream is already supported in the area of the new user, then 
the QoS negotiation process need not be carried out; rather, the stream 
is simply multicast to the new user. Thus, an end system QoS agent has 
only to deal with QoS management on its own system. All issues concern- 
ing negotiations with, resource reservations at and adaptation of remote 
components are part of the work of the network QoS agents. End system 
QoS agents simply send messages to their neighboring agents, stating the 
types and qualities of documents/media they would like to receive. 

The teleteaching application we use as an example supports the delivery of 
a lecture from a given site to students located in several remote locations. The 
delivery consists of video and audio from the lecturer. In addition, the lecturer 
may present multimedia documents stored locally or in some other locations. 
Students have the possibility to ask questions, but they first have to get 
permission to do so. In this prototype, we allow only one student to talk at a 
time. The lecturer is always allowed to talk. In addition, it is possible to record 
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Figure 1 Architecture of a receiver’s machine 



a whole session and store it as a multimedia document in the multimedia 
databases. Thus, lectures may be later reviewed by students when preparing 
for exams. We decided not to build a new application from scratch, but to use 
the existing MBone tools (Kumar 1996) and protocols in combination with our 
QoS user interfaces and protocols (Hafid and v. Bochmann 1996) (however 
modified as described above). The architecture of a receiver’s end system can 
be found in Figure 1. In the current version of the application, a quality switch 
for a given medium is implemented by stopping the corresponding MBone tool 
and starting it again with a different multicast address. We plan to change 
the MBone tools’ implementation to perform such a switch internally in order 
to provide a smoother quality switch. 
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Abstract: 

Continuous media differ in their nature from discrete media, in that streams provide with 
a flat structure of data or even with loss of structure instead of single highly structured multi- 
typed discrete data units. Streams use simple communication concepts, since they are 
directed flows. Discrete media however, obey in most cases a complicated communication 
protocol. Streams are mass transportation vehicles, whereas discrete media cope with less 
mass of data but usually with more information about a state change of the communicating 
components. End-to-end control can be achieved by sensoring the effect of system activities 
and by feeding them back to the related input. Controlling signals will be issued when certain 
invariants of the system get violated. Models of which obey with components of a continu- 
ously operating system, a continuously sensoring and discretely decision-taking component. 
Whereas the continuous system is forward-oriented, the sensoring and decision-taking com- 
ponents are backwards. A synthesis of these two aspects provides with the basic end-to-end 
QoS control architecture. 

Keywords: 

End-to-End QoS Control, Control Systems, Stream Engineering, Monitoring 

1 INTRODUCTION 

One of the most important concept in system engineering is to permanently observe and con- 
trol an open behaviour to achieve best qualities of services. Here behaviour is called open 
because the system’s background activities will have impacts to the service provision. The 
‘background noise’ may cause delays, bandwidth crashes, or unacceptable jitter during trans- 
mission etc. Hence, a major desire in continuously operating systems is the permanent con- 
trol of the quality of operation and optimal use of resources. One of the first experiments with 
flow engineering mechanisms have been resulted from the realisation of the “multimedia 
enhanced transport system” (Campbell etal 1996). The system comprises engineering com- 
ponents to schedule flows, to shape flows according to the token bucket scheme, to filter jitter 
and to control quality adaptations. A more specification-oriented approach of resource adap- 
tations to QoS constraints has been presented in (Franken etal, 1996). 

2 Liquid-level Monitoring Paradigm 

The paradigm of the “water-level monitor” from (Alur etal, 1996) is very suitable for intro- 
ducing and reasoning about continuous end-to-end QoS control because the paradigm com- 
prises with the appropriate componental architecture. The liquid-level monitor system 
consists of a liquid container with a constant sink and a controlled source. The effect of the 
continuously operating sink and source can be monitored at the liquid level. Now, the liquid 
level Y(t) must be controlled by switching the source on and off, such that the liquid level is 
in between of some upper UB and lower bound LB. Furthermore, switching on and off the 
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source effects the volume of the liquid container after a delay of e.g. 1 second. This paradigm 
is drafted in figure (1) and consists of the 4 components: source, container, monitor and sink. 
The source is characterized by the stream Q^t) conveyed by a server, e.g. a pump and a delay 
when the effect of the server gets observable; the container is characterized by the conveyed 
volume, composed from the current liquid level Y(t) and the container’s size A; the monitor is 
characterized by the system invariants and thresholds not to be violated resp. to generate con- 
trol signals to the source; and finally the sink is characterized by his characteristic size 
which allows the stream Qj(t) to flow out of the container constantly. 

3 STREAM BALANCING APPROACH 

By balancing the input and output streams of the container according to (Schlitt 1993, Jde- 
Meer 1996) we get the accumulated volume by equation V{t) = Q^{t) - 1 ) . Inde- 

pendent from the source behaviour the output stream is assumed to be constant. 

The Liquid-level Monitoring System can 
easily be translated towards a multi-media 
servicing system. The components 
‘source’, ‘sink’ and ‘container’ are the 
multi-media producing and consuming 
components with accumulating facilities in 
between. The multi-media producing and 
consuming components usually operate 
independently, i.e. generating the streams 
Qi(t) and Qg{t) respectively. Hence, the 
network must be able to provide with stor- 
ing facilities characterized by the size A of 
units to be stored, e.g. pages or bytes, but 
likely different from the units a^ consumed 
by the sink. 

From equation (1) the stream-balancing 
equation and by replacing the network’s 
output stream Qj[t) by the assumed constant speed of the sink stream the differential equa- 
tion describing the actual accumulation level Y(t) of the network storing capacity is as given 

inequation (2): ^(0 = “ ^ * C;(0(2) 

Now, the monitor has to control the level of stored units in the network, such that some 
given upper UB and lower bound LB are never exceeded. In order to deal with the delay 
requires by the monitor an upper UTh and a lower threshold LTh that mark the filling respec- 
tively emptying capacities during delay. Since, in the paradigm the delay shall be a second 
and the source speed is assumed to be 30 frames per second and the sink shall be 20 frames 
per second, the upper and lower thresholds and bounds derive to: UB=100, UTh-90, 
LTh=40, LB=^20 frames. The monitor comprises with the functionality of controlling the sys- 
tem invariants by permanently sensoring characteristic variables, e.g. Y(t), and by issuing of 
control signals, e.g. ** server-on** or ** server-off** when certain thresholds have been reached. 
Similar, the network component is modelled by his capability to accumulate input and output 
streams. The sink component has a constant stream behaviour, characterized by the through- 
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put of the display of presenting units of size Qq with the speed of v^. 

In the paradigm, the output stream is said to be constant, the input stream is not. Now, 
by integrating equation (2) and by replacing the input stream Q^t) by aVt with the opera- 
tion time t per frame a/, we get able to calculate the accumulation level Y of the network 
buffer for a given time period of t seconds, 
f + 1 

y = J ^-Q^ + j^dt = -Q^t + a. \nt^'^^=-Q^t + a. \n{t+l) 

1 * 

. Notice, in order to simplify the solution of the determinate integral the lower bound of the 
time interval has been chosen to be 1. The solution describes the streaming behaviour for a 
time interval of e.g. 7 to r+7 seconds with frame generation at the server site as a function 
over time. For example, the monitor could signal to increase or lower the frame generation 
speed. 

From equation (2) we 
are able to immediately 
derive the componental 
architecture of the moni- 
tor paradigm as given in 
figure 2. The compo- 
nents of the system, i.e. 
source, network and sink 
obey stream-manipulat- 
ing functionalities of the 
equation (2). The inte- 
gral operator defines the 
accumulation, the stream 
balancing the subtraction 
point, the openness of a 
stream the independent 
resp. constant behaviour and Y(t) the measurement (sensoring) point. 

However, the behaviour of the monitor com- 
ponent infact is not captured by equation (2). 
Therefore, the control procedure, e.g. of the 
monitor component, is to be handled sepa- 
rately. The system invariants on time and the 
accumulated unit level which is under control 
do not occur in the stream model. The control 
model describes the feeding-back end-to-end 
control path. This relationship is drafted in 
figure 3. By the stream model the translation 
of the system streams into an observable vari- 
able Y(t) is obtained and will be fed back into the control path. The control component moni- 
tors the continuous level function Y(t) and time function X(t) and produces appropriate 
control signals in order to steer the server. The variables X(t) and Y(t) are ‘valuated' by the 
control component. Whereas Y(t) represents the level of unit accumulation in the system 
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buffer X(t) represents the explicit and continuous evolution of time in the control model. An 
example of decision-taking activity is: *ify = UTh then signal(server~on)\ Examples of con- 
tinuous activities are the system’s accumulation between the lower bound LB and the upper 
threshold UTh: ‘while y<UTh then incr(y-¥l0y or between the upper bound UB and lower 
threshold LTh: ‘while y>LTh do incr(y-20y or the system’s delay: ‘while x<delay do 
incrix^-l), inaiy^lOy. 

4 CONCLUSIONS 

A combination of the continuous stream model with the control model to a composite model 
consisting of the streaming path of Q-(t) (QJt),V(t)) and of the feed-back control path 

((y(/), X(r)) (signals)) gains the appropriate ent-to-end QoS architecture. It seems to 
be very adequate because the composite model allows the synthesis of both the capturing of 
continuously changing system activities with discrete decision taking of the control part. The 
discrete approach of the control model is suitable to represent the decision-taking machine. 
In contrast, streams obey duration, capacity, and direction and thus provide with quantitative 
properties that vary over time. Both systems the discrete one and the continuous one can be 
connected without further translations. And infact, the view of the system shall be taken sep- 
arately from the view onto it. At the final end the viewpoint approach of ODP (IS 10746, 
1995) gets convincingly achieved. However, it must be critically remarked that the presented 
approach has not yet been evaluated against a sophisticated multi-media service. But, as 
shown, control theory fits nicely with the requirements of end-to-end (JoS Control and gives 
powerful means on hand to reason about designed QoS Architectures. 
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Abstract 

Specification of storage systems by means of user-oriented Quality-of-Service attributes 
is the key to ease of use and efficient resource utilization. Attribute-managed storage 
systems hide details of the underlying storage systems through virtual store 
abstractions — ^units of storage with quality of service guarantees. The mapping of virtual 
stores onto physical storage devices can be optimized to achieve high level goals such as 
balancing system performance against total system cost. We demonstrate the feasibility 
of this approach with a prototype matching engine called Forum. 

Keywords 

storage systems, attribute-managed storage, network-attached storage, quality of service 

1 INTRODUCTION 

The configuration and management of large quantities of on-line storage is a non-trivial 
task — yet it is central to the functioning of most operating system services. The 
difficulties inherent in the problem are compounded by sheer scale — ^tracking the 
thousands of physical and logical devices required to support a few tens of TB of data. 

Consider first the problem of initial configuration of storage devices so that performance 
and availability goals are met. Now consider configuration with performance guarantees 
in the face of a workload that is constantly shifting, and a storage pool that is changing 
as new devices are added and obsolete or defective ones removed. Compound with this 
the desire to share the storage across multiple computer systems with nearly arbitrary 
interconnection topologies via storage fabrics like Fibre Channel. Finally, the 
introduction of network-attached storage devices will only exacerbate the problem. 

Things have reached the point where the cost of managing a device is several times the 
purchase cost. The planning for a medium-scale (few TB) installation can require many 
months. At the same time, these problems represent a significant opportunity: storage 
hardware was about a $50b business in 1995, and about 25% of information technology 
budget expenditures (Network Storage Conference, 1996). Improving the way storage is 
used and managed could be a huge win: for users, for system managers and 
administrators, and for computer system vendors. 

2 ATTRIBUTE-MANAGED STORAGE 

Most existing approaches to storage management operate at too low a level: they require 
people to allocate and configure disks or disk arrays to particular pieces of work, but 
provide little help to them in doing so. For example, logical volume managers [Chang90] 
provide a number of low-level mechanisms to allow multiple disks to be grouped together 

* Elizabeth Shriver was supported by the NFS grant CCR-9504175. 
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Figure 1. The life-cycle of the self-configuring, self-managing storage system. 

in different ways, but provide no additional help in predicting performance effects, or 
determining the best data layout to use. 

Instead, our approach is to abstract the gory details of the underlying storage system by 
having the storage system present a virtual store abstraction. Each virtual store represents 
a unit of storage and can hold a large-scale data object such as a file system, relational 
database table, or a single large file. It has a set of Quality-of-Service (QoS) attributes 
such as size (capacity), performance capabilities, and resilience (a set of availability and 
reliability metrics) which satisfy requirements of the application workload. In turn, 
virtual stores are mapped onto physical storage devices, each having a set of capability 
attributes such as capacity, performance, and availability. 

The QoS attributes of virtual stores are high-level storage system goals, or requirements: 
they specify what the storage system is to achieve, not how it is to do so. This allows us 
to automate the mapping while taking into account multiple simultaneous needs like 
bandwidth, I/O rate, capacity, or system cost. 

There are several advantages of the attribute-based approach. For example: 

• automated mappings can be made in minutes rather than the weeks needed for 
manual configuration; 

• because the storage system knows the goals of its clients, it can adapt to changes 
in physical configurations automatically; 

• the optimization engine can be directed to meet different goals, such as how to 
balance system performance against total system cost; 

• the same optimization technology that can generate initial assignments of 
workload to devices can be used to ask “what if?” questions to explore the effects 
of future changes in configuration or load; 

• once the system is running, the QoS goals for the virtual stores can be monitored, 
and adjustments made in the assignment. 

Figure 1 shows several ways in which we envision this technology will be applied. 






Using attribute-managed storage to achieve QoS 



205 



3 THE FORUM PROJECT 

We are actively developing technology to validate the concept of attribute-managed 
storage. We have developed a prototype assignment engine (or solver) called Forum. 

We model the assignment of workload to devices as a multiple-constraint, multiple- 
knapsack optimization problem. Treating this as a general optimization problem, rather 
than focusing specifically on the storage-assignment task, has generated great flexibility 
in the prototype: for example, we can easily add system goals such as minimizing the 
expected reorganization cost as new workloads are added. 

The main Forum solver components are: 

• a set of device performance models for utilization, throughput, and response time 
based on our prior work [Ruemmler94, Wilkes95, Wilkes96]; 

• a set of QoS constraints that express things like “you cannot put more data on a 
device than it can hold”, and “the device utilization cannot be greater than 1”; 

• sets of device parameters that describe the capabilities of available devices; 

• a workload model which captures variability in requirements of an application; 

• a search engine, which explores the potential space of assignments. 

As the solver runs, it uses the device models to decide whether or not an assignment can 
be made. Although the optimization problem is NP-hard, we have been able to adopt 
several heuristics from the literature [Toyoda75]. We have found that remarkably simple 
ones produce pretty good results: the solver is capable of assigning several thousand 
objects to hundreds of devices in a few minutes. 

In addition to dealing with performance goals, the solver can handle availability 
requirements [Wilkes91]. An additional component, called Corbel (written for us by 
Khalil Amiri of CMU), builds and solves Markov models to predict the availability and 
reliability properties of all the possible configurations of the storage devices of interest. 

4 VALIDATION 

Although our prototype assignment engine claims to make assignments that support 
probabilistic QoS guarantees, it is essential to compare our models against the real world 
to see how they do in practice. To this end we are performing a set of validation 
experiments. We take both synthetic and more realistic workloads (such as database 
benchmarks), and compare the predicted performance on the assignment emitted by the 
solver with the actual behavior of the running workload. Our goal is to be slightly 
conservative: we want to keep the target system well-utilized, but for its performance to 
remain inside the bounds predicted by the solver which, in turn, must fall within the 
bounds required by the workload. 

We have operated under the premise that the more information is provided to the 
optimization engine about a workload, the better solution it can provide. However, we 
also want the minimal set of attributes required to generate good solutions. Figure 2 
shows the results from one of our tests: allowing for closed arrival processes in the 
internal performance model makes for a significantly more accurate estimate of system 
performance. 

The primary validation test has centered around a decision support database benchmark. 
We first configured our system using the best expert advice we could find, and ran the 
benchmark. The performance measurements were then used as requirements for 
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Figure 2. Results of the solver validation for a set of workloads assigned to an HP97560-300 disk. 



assigning the same workload to the same system, with the goal of minimizing the number 
of devices used. The resulting assignment used fewer devices, and system performance 
matched the requirements-the benchmark execution time was within 2%. 



5 CURRENT WORK 

Our current work lies in several activities: 

• enhancing the workload model to include interactions between individual access 
streams and the data objects that they access; 

• extending the solver with different algorithms; 

• continuing to improve the model of device performance, adding models of disk 
arrays and using a composite model of device performance that accounts for the 
effects of cache and request queueing policies; and 

• validation across a broader range of realistic workloads. 

In the future, we plan to embed the Forum smarts in network-attached storage devices 
(see http://www.hpl.hp.com/SSP/NASD for more information), which will provide us 
with ways to support performance and security guarantees in shared storage systems. The 
way in which this is done is going to have a large impact on future operating systems and 
the way they access their storage. 
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1 INTRODUCTION 

A growing class of distributed applications require end-to-end quality of ser- 
vice (QoS) guarantees (such as bandwidth, latency, jitter, and level of re- 
liability). These applications include telecommunication systems {e.g., call 
processing and switching), avionics control systems {e.g., operational flight 
programs for fighter aircraft), multimedia {e.g., video-on-demand and tele- 
conferencing), and simulations {e.g., battle readiness planning). In addition 
to requiring QoS guarantees, these applications can benefit by being built 
with flexible and reusable components, which can reduce development effort 
and increase software quality. 

Requirements for fiexible and reusable components motivate the use of 
Distributed Object Computing (DOC) middleware and Object Request Bro- 
kers (ORBs). Example DOC ORBs include OMG’s Common Object Request 
Broker Architecture (CORBA), Microsoft’s Distributed COM (DCOM), and 
JavaSoft’s Remote Method Invocation (RMI). Following in the tradition of 
Remote Procedure Call (RPC) toolkits like Sun RPC and OSF DCE, DOC 
ORBs are well-suited for conventional request/response-style applications run- 
ning on low-speed networks. 

However, the QoS specification and enforcement features of current DOC 
middleware and ORBs, as well as their performance levels, are not yet suit- 
able for applications with hard real-time requirements (e.g., avionics mission 
computers) and stringent statistical real-time requirements (e.g., teleconfer- 
encing). Conventional DOC ORB specifications and implementations are char- 
acterized by the following deficiencies: 

• Lack of QoS specification and enforcement - Conventional DOC 



Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
© 1997 IFIP. Published by Chapman & Hall 




208 



Panel / 



ORBs do not define APIs that allow applications to specify their end- 
to-end QoS requirements. Likewise, existing DOC ORB implementations 
do not provide support for end-to-end QoS enforcement between applica- 
tions across a network. For instance, CORBA provides no standard way 
for clients to indicate the relative priorities of their requests to an ORB. 
Likewise, there are no means for DCOM or RMI clients to inform an ORB 
how frequently to execute operations that must run periodically. 

• Lack of real-time features - Conventional DOC ORBs do not provide 
key features that are necessary to support real-time programming. For in- 
stance, although the CORBA inter-operability protocol (GIOP) supports 
asynchronous messaging, there is no standard programming language map- 
ping for exchanging ORB requests asynchronously. Likewise, the DCOM 
and RMI specifications do not require an ORB to notify clients when trans- 
port layer fiow control occurs. Therefore, it is hard to write portable and 
efficient real-time applications that are guaranteed not to block indefinitely 
when ORB endsystem and network resources are temporarily unavailable. 

• Lack of performance optimizations - Conventional ORBs incur signif- 
icant throughput and latency overhead. These overheads stem from exces- 
sive data copying, non-optimized presentation layer conversions, internal 
message buffering strategies that produce non-uniform behavior for dif- 
ferent message sizes, inefficient demultiplexing algorithms, long chains of 
intra-ORB virtual method calls, and lack of integration with underlying 
real-time OS and network QoS mechanisms. 



Although some operating systems, networks, and protocols now support 
real-time scheduling, they do not provide integrated end-to-end solutions. In 
particular, QoS research at the IPC and OS layers has not necessarily ad- 
dressed key requirements and usage characteristics of DOC middlware such 
as CORBA, DCOM, or RMI. For instance, research on QoS for communication 
systems has focused largely on policies for allocating network bandwidth on 
a per-connection basis. Likewise, research on real-time operating systems has 
focused largely on avoiding priority inversions and non-determinism in syn- 
chronization and scheduling mechanisms for multi-threaded applications. In 
contrast, the programming model for developers of DOC applications focuses 
largely on invoking remote operations on distributed objects. Determining 
how to map the results from QoS work at the IPC and OS layers to DOC 
middleware is an important open research topic. 

Meeting the QoS needs of next-generation distributed applications requires 
much more than defining IDL interfaces or building real-time scheduling into 
ORBs. It requires a vertically integrated architecture that can deliver end-to- 
end QoS guarantees at multiple levels of an entire distributed system. This 
panel will describe the architectural features and optimizations that are nec- 
essary to develop Distributed Object Computing middleware that can deliver 
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end-to-end QoS guarantees to applications. The topics presented by the pan- 
elists will include: 

• The enchancements required to existing DOC specifications (such as OMG 
CORBA) that will enable applications to define their Quality of Service 
(QoS) requirements to ORB endsystems. 

• Key architectural patterns required to build real-time ORB endsystems 
that can enforce deterministic and statistical end-to-end QoS guarantees 
to applications. 

• Strategies for integrating I/O subsystem architectures and optimizations 
with DOC middleware to provide high bandwidth and low latency guaran- 
tees to distributed applications. 

• Overview of forthcoming CORBA specifications (such as the Notification 
service, Messaging service, Streaming service, and passing objects by value) 
that address QoS requirements. 

• Techniques for associating an IDL interface with multiple implementations 
that can provide different QoS characteristics. 

We look forward to your participation in the panel. 
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Abstract 

Over the last years, Quality of Service (QoS) has evolved as a research field to sup- 
port new application types in general, very often in networked, computer systems. 
The most prominent of these applications are distributed multimedia applications 
which transmit and process audiovisual information streams. Due to their real-time 
nature, any correct processing and transport of these data must take timing aspects 
into account. The goal of QoS mechanisms is to ensure that the overall presentation 
of audiovisual data to the user respects these properties in an end-to-end mode. 

In this paper we give an overview about the terms, issues and trends in the provi- 
sioning of QoS whereby we concentrate on principles and architectural aspects. We 
briefly describe the fundamental steps followed by systems offering QoS and review 
the IntServ work evolving in the Internet as an example for a prominent QoS model. 
Furthermore, past, actual, and future issues are discussed which we consider to be 
important for QoS architectures. 



Keywords 
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1 INTRODUCTION 

Traditional applications such as information processing, number crunching, text 
processing, etc. operate in a time-sharing environment without any hard time con- 
straints. The system responds to a user interaction as soon as possible but lacks sup- 
port for real-time data. New applications, especially multimedia applications which 
make use of continuous-media data such as audio and video, place other demands 
on distributed computer systems because they require time-dependent data process- 
ing. ‘Correctness’ in such a system is - in addition to the traditional, static 
meaning - determined by whether deadlines are met or not. Furthermore, the pro- 
cessing demands of digital audio and video data are typically large, i.e., although 
the available capacity is sufficient, it is not abundant to serve properly a continuous- 
media data presentation. 

Quality of Service (QoS) mechanisms promise to ensure that these requirements 
are fulfilled. Most work on QoS is directed towards the support of multimedia appli- 
cations. However, beneath multimedia applications, other applications, e.g., from 
the areas of distributed simulations and system control, require proper timing con- 
siderations as well. Yet, the QoS mechanisms developed for multimedia systems are 
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not appropriate for all of them; e.g., due to different base assumptions and sensitiv- 
ity. Here, we concentrate on QoS mechanisms for multimedia systems. 

QoS is defined as the set of parameters which defines the properties of media 
streams. The notion of QoS is different for the various system layers, e.g., the 
description of QoS at the application layer is usually at a higher level than that at the 
network layer of a communication system. The required QoS depends on various 
factors such as the used media (video, audio, etc.), the coding format used to encode 
the data, the application and the type of the application. For instance, the QoS of a 
video conference is different from that of a video retrieval application, since the dia- 
logue-mode communication of a conference requires a short delay which is not as 
important for playback applications. 

Applications negotiate the desired QoS with the affected components such as the 
network or with a general QoS management agent which performs the negotiation 
with the various components on behalf of the application. These negotiations usu- 
ally take place at the start of the application, i.e., at the setup of the QoS. 

Resource management systems that include mechanisms for data streams with 
guaranteed or statistical QoS have become a key issue in the support of multimedia 
applications (e.g., [22][11]). Those systems take care of the coordination of media 
streams, the interfacing between layers of protocol stacks as well as further mecha- 
nisms such as process, disk and bandwidth scheduling in order to enforce the appro- 
priate data handling. Most of the involved mechanisms are developed for a 
completely error-free presentation of continuous-media data at the user interface. 

In today’s networked environments we still encounter many data paths via net- 
works and communication protocols which are not capable of providing a guaran- 
teed real-time service. In such set-ups it is important to decide which data item must 
be presented at the user interface and which data items may be discarded. The 
approaches for this are known as “scaling” and “filtering” of media data streams. 

In this paper we give an overview about terms, issues and trends related to the 
support of QoS, whereby we concentrate on principles and architectural aspects. In 
the next section, the fundamental steps followed by systems offering QoS are 
described. Then we briefly review the IntServ work evolving in the Internet as an 
example for a QoS architecture. In Section 4 we discuss past, actual, and future 
issues which we consider important for QoS architectures. Finally we summarize 
the paper in Section 5. Despite the fact that QoS is an end-to-end aspect, we focus 
within this paper mostly on communication system aspects and their capabilities to 
support QoS because this is the most active area. 

2 NOTION OF QUALITY OF SERVICE 

Support for configurable, realizable and maintainable QoS is expected by numerous 
distributed applications. As such, it must necessarily be provided on an end-to-end 
basis from the source of data to the final perception of the data by the consuming 
user. This means that all hardware and software components involved in the overall 
tasks of the applications must provide appropriate methods and handle the data 
accordingly - from the local resources at the sender side via the transport system 
and networks, to the local resources at the receiving side. This applies to end-sys- 
tems, servers, and networks as well as to system software and applications. 
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Most of the participating resources are shared among users and various pro- 
cesses. One approach would be to (over-) design them based on peak demands such 
that never any collisions between demands of different applications can occur. Then 
it would not be necessary to provide any resource management functionality. Yet, 
such a scenario would result in huge costs and low resource utilization and, hence, 
is typically not realizable. So if we have limited resources only, we may use filtering 
and scaling mechanisms which adapt the generated workload to the available 
resources by changing the characteristics of the transmitted data stream, e.g., lower- 
ing the frame rate of a video stream. Yet, these techniques cannot offer a reliable, 
constant QoS during the run-time of an application. We believe that typical distrib- 
uted computer systems still are and will be so for a considerable amount of time in 
the “window of scarcity” illustrated by Anderson et al. in . Thus, to provide a con- 
stant QoS during the run-time of an application, resource reservation and schedul- 
ing techniques must be applied. 

There are still different perspectives on QoS as observed by service providers and 
service users, whereby for the former efficiency of resource utilization is the focal 
point of QoS, while to the latter the completeness of parametrization of the service 
is most important. These different perspectives have led to different service models, 
which in the past did not allow for quantitative mappings between them. Hence a 
goal to be strived for must be an integral view of QoS for both, providers and users 
of a service. This can be achieved if both components are integrated into one system 
as for example when the operating system offers services to the applications like 
process scheduling, but is very difficult when multiple parties have to cooperate as 
in the case of a network services provider and an application program, which natu- 
rally pursue very different objectives. 

2.1 QoS provisioning steps and components 

In order to provide QoS by using resource reservation and scheduling, several steps 
must be performed in turn at each system and component participating in the end- 
to-end application . These steps can be divided into the QoS negotiation phase, con- 
sisting of (1) QoS specification, (2) Capacity test and QoS calculation, and (3) Res- 
ervation, and the data transmission phase, where the negotiated QoS is enforced by 
appropriate resource scheduling. 

Overall, several resource management components interact to provide QoS assur- 
ance: Applications, QoS translators, admission control, resource scheduler. Addi- 
tionally, further components are needed, for example, a resource monitor which 
measures the availability of resources and monitors whether the promised QoS is 
actually provided. Besides these local mechanisms at the end-systems and routers, 
resource reservation protocols are needed. They exchange and negotiate QoS speci- 
fications (accumulate in FlowSpecs) between the participating systems. These pro- 
tocols perform no reservation of required resources themselves, but are only the 
vehicles to transfer information about resource requirements and to negotiate QoS 
values - the reservation itself is left to local resource management modules. 

2.2 QoS classes and layers 

Several classes of QoS are typically distinguished, the extreme on one side is a hard 
“deterministically guaranteed QoS” where the reservation is based on peak require- 
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ments and worst-case assumptions, the other is the “best-effort” approach where no 
reservation is made at all (and should therefore, at least with respect to QoS, better 
be called “no-effort”). Between these exist various forms of weaker QoS (statistical, 
predictive) based on average case and predicted assumptions. The hard QoS guaran- 
tee, which has been the focus of the early work on QoS support, requires more 
resources and is more costly, than the 'weaker’ approaches. Yet, in the latter cases, 
needed resources may not be available leading to worse quality. 

The notion of QoS is very different at the various system layers, e.g., in [17], four 
layers of QoS are distinguished: User QoS, Application QoS, System QoS and Net- 
work QoS. The user QoS parameters describe requirements for the perception of 
multimedia data at the user interface. The application QoS parameters describe 
requirements for the application services possibly specified in terms of media qual- 
ity (like end-to-end delay) and media relations (like inter/intra-stream synchroniza- 
tion). The system QoS parameters describe requirements on the processing and the 
communication services resulting from the application QoS in quantitative (e.g., 
bits/s or processing time) and qualitative (e.g., multicast, inter-stream synchroniza- 
tion, error recovery or ordered delivery of data) terms. The network QoS parameters 
describe requirements on network services (e.g., network load or performance). 
Since each of these layers needs the QoS specified in its own terms, a mapping 
between them is necessary. While this mapping is an important issue for all net- 
worked multimedia applications, no overall solution has been found yet, but only 
partial approaches for simple conversions, e.g., between transport and network 
layer, have been devised. 

An interesting approach to coordinate all the different negotiations taking place 
between peers and different layere is the QoS broker architecture [12], in which the 
broker is a central point for all negotiations taking place, thereby isolating the nego- 
tiation partners, which releases them of the burden of knowing all the details for 
communication between them. 

2.3 QoS specification 

In general, three QoS parameters are of main interest with respect to the transport of 
continuous-media data: throughput, delay and reliability. 

Throughput, as the most prominent QoS parameter, specifies how much data 
(maximum or average) is to be transferred within the networked system. In general, 
it is not sufficient to specify the rate only in terms of bits per second but should 
describe the packetization, e.g., by specifying the maximum and the average packet 
size and the packet rate. The reason is that the QoS scheme shall be applicable to 
various networks as well as to general-purpose end-systems and the costs of opera- 
tions such as buffer management, timer management, etc., which play an important 
role for protocol processing, are related to the number of packets processed (and are 
mostly independent of the packet size). Delay as the second parameter specifies the 
maximum delay observed by a data unit on an end-to-end transmission. Reliability 
pertains to the loss and corruption of data, for that, loss probability and the method 
for dealing with erroneous data should be specified. Jitter, the delay variance, is the 
fourth QoS parameter typically considered. It is the result from varying delays dur- 
ing processing and transmitting the data. It can be smoothed by hiffering at the 
receiver side which, however, increases the end-to-end delay. All QoS parameters 
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are closely related: The smaller the overall bandwidth of a resource is compared to 
its load, the more messages will be accumulated in front of it and the larger the buff- 
ers need to be to avoid loss. The larger the buffers become, the more likely mes- 
sages need to wait to be serviced, that is, the larger the delay will get. 

The parameters used within the workload description specify what amount of 
data the source intends to transmit. This must be viewed in the context of a work- 
load model which specifies how the source generates data and feeds it into the sys- 
tem. 

2.4 Adaptive mechanisms 

Adaptive methods, using scaling and filtering, may be seen as an alternative to res- 
ervation-based QoS provisioning, e.g., if reservations are not supported by the used 
networks. These techniques adapt the generated workload to the available resources 
by changing the characteristics of the transmitted data stream, e.g., lowering the 
frame rate of a video stream, and, thus, allow a smooth decrease in quality. 

To perform scaling, a feedback control loop is introduced - the load state of net- 
work and local end-system resources are monitored and if significant changes occur, 
appropriate actions must be taken to reduce the load. This reduction can be achieved 
in various ways: by explicit communication between receiver and sender (the 
receiver informs the sender to slow down), completely in the network on a hop-by- 
hop basis, or by feedback from congested network nodes to the sender. Multiple 
systems have been developed for such scaling especially in the unicast case. 

Implementing scaling mechanisms within each single application forces pro- 
grammers to construct their own mechanisms. Further, leads to interworking prob- 
lems between applications in case of several streams being scaled simultaneously 
and raises questions about fairness and balancing between streams. These problems 
can be solved by ’middleware* approaches (e.g., [9]) where media scaling methods 
are integrated into a general system support for multimedia. 

Distributed applications involving many participating systems are often of heter- 
ogeneous nature and, hence, cannot be supported by the described scaling mecha- 
nisms. This can happen, for instance, if several multicast receivers require different 
amounts or different encoding of data from the sender, e.g. due to varying network 
capabilities or due to different processing capacities of the receivers. Such a sce- 
nario can be supported in multimedia applications by using filtering mechanisms 
(e.g., [13]). Then, an intermediate node within the network changes the amount of 
transmitted information - by re-coding or, the simpler case, by removing parts of 
the data and forwarding only a subset of the full information. 

The removal of data requires that the full stream has been encoded into a hierar- 
chy of information layers, as is for instance possible with MPEG-2. Then the appli- 
cation can split the data into streams and sends them independently, as has been 
described, e.g., in [8] using one ST-2 stream and in [4] using one IP multicast group 
for each layer. A refinement is the use of error detection within the receiver-driven 
layered multicast approach ([10]) where receivers start out to receive the base layer 
and add further enhancement layers until they have either subscribed to all layers or 
until experienced packet loss. Such approaches can result in synchronization prob- 
lems because the independent transmission of the layers can lead to differing delays 
among the layers (e.g., due to the use of different routes or priorities). This can be 
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avoided if the application transmits one stream, but describes the structure of the 
stream (e.g., as part of the FlowSpec), allowing receivers to specify filters to be 
installed in the network which strip off information not to be transmitted to that 
receiver [21]. 

3 QUALITY OF SERVICE ARCHITECTURES 

QoS is inherently an end-to-end requirement since for the user, the whole concept 
of QoS is only attractive if the presentation at the user interface satisfies his/her 
needs. This means that an overall approach to QoS provisioning is necessary. 
Unfortunately, most work on QoS support concentrates on certain aspects only, e.g., 
how to offer QoS in the communication system (which is undoubtful among the 
most important) such as the work on Tenet (at UC Berkeley and ICSI) [2] or on 
ATM. Only few QoS architectures using an end-to-end view have been developed 
which also take end-system components (CPU, memory, disk, ...) into account, 
e.g., HeiTS/HeiRAT (at IBM Heidelberg) [19] [20] and QoS- A (at Lancaster Uni- 
versity) [5] being among the first, and these most often also lack one or another 
component. In the following, we briefly describe the approach followed in the Inter- 
net community due to its foreseen impact on future use of the Internet. An overview 
about QoS architectures can also be found in [6]. 

The goal of the Integrated Services (IntServ [14]) activities, in relation with the 
work on the RSVP protocol, is to provide a general solution for QoS guarantees in 
the future internet. The Resource ReSerVation Protocol (RSVP) [24] is a reserva- 
tion protocol in the Internet suite used to transport FlowSpecs that adhere to Intserv 
rules between resource managers to perform reservations for flows. The primary 
background of RSVP can be seen within conferencing applications, yet its target is 
to solve the requirements of other applications as well. 

RSVP adds reservation to the existing resp. up-coming Internet protocols (IPv4 
and IPv6), relying on those protocols for the interchange of data. RSVP is directed 
towards the support of large receiver groups, therefore, it is receiver oriented. It 
allows for the definition of filter specifications for reservations made for a flow, and 
it provides means to merge reservations. 

Instead of hard state controlled mainly by connection-setup and -release, RSVP 
keeps soft state. This state, created similarly to hard state by the exchange of reser- 
vation messages, must be refreshed by reservation updates periodically, otherwise, 
if no such update is received, the reservation times out and is removed. 

Two types of descriptions are used for the QoS specification: the traffic specifica- 
tion (TSpec) describes the behavior of a flow, and the service request specification 
(RSpec) describes the service requested under the condition that the flow adheres to 
the restrictions of the TSpec. 

On this basis, various services are defined. Guaranteed QoS requests that the 
maximum end-to-end delay of a packet is strictly limited to the given value in the 
RSpec, under the condition that the flow sticks to a certain traffic pattern. TTiis spe- 
cific service is useful for applications with hard real-time restrictions such as audio 
transmissions. Controlled-load service requests that all network elements behave 
under any circumstances for a reserved flow that describes its traffic characteristics 
as they would for a best-effort flow in a situation of light load and without conges- 
tion. This service is useful for multimedia applications such as some video confer- 
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encing systems which work well on lightly loaded networks without reservations 
although they fail under heavy load. Committed rate QoS requests that all network 
elements between the source and the targets in a flow maintain the data rate; the 
overall delay may be quite large, and losses are more probable than with the ser- 
vices mentioned above. 

Communication system QoS support (at least for deterministic guarantees) using 
reservations can only be successful if the data transmission uses exactly the same 
route on which the reservations have been made (at least as long as no failure 
occurs). Thus, opportunistic re-routing - route changes due to slightly better metrics 
but which are not inevitable necessary - must be inhibited, i.e., ’route pinning’ must 
be done, affecting the operation of IP. Route pinning has been discussed several 
times within the RSVP working group and is currently not provided. Therefore, a 
hard QoS guarantee cannot be given by RSVP. 

4 PAST, ACTUAL AND FUTURE ISSUES 

Many architectures and pieces for QoS support have been proposed during the last 
years. All of these consider only some aspects of the overall end-to-end problem. 
While such an approach has the advantage of functional decomposition and reduced 
complexity, it has the drawback of necessary transitions with the potential risk of 
information loss. Therefore, an integrated approach or at least smooth transitions 
among the various components would be helpful. 

What we believe to missing in general are large scale end-to-end experiences. 
Furthermore, several issues must be attacked to provide a complete solution for QoS 
provisioning. Among these are the (architectural) topics of QoS routing, pricing, 
security, support for heterogeneous systems, scalability, and reservations in advance 
which will be discussed briefly in the following. 

4.1 Local components 

Some effort within the research community has been devoted towards QoS provi- 
sioning in servers and end-systems, e.g., CPU and disk scheduling mechanisms. 
However, most applications do not use such mechanisms resp. are not executed on 
systems providing such means. So, are these mechanisms still needed for end-sys- 
tems or servers ? The answer is yes, of course, for servers as well as for other shared 
resources and systems. For most end-systems which serve only one user and which 
are used for relative uncritical applications such as video playback, we expect that 
CPU scheduling and memory management will not find wide-spread distribution. 
Yet, for high-end usage, e.g., processing of large video streams, and high-quality 
applications, e.g., video recording, there will be a need for such techniques. 

4J! Routing 

QoS driven routing algorithms are needed for the efficient establishment of reserva- 
tions. These algorithms suggest one or multiple suitable paths towards a given target 
considering a given set of QoS requirements. An attempt is then made to make a 
reservation on such a path. Without appropriate routing mechanisms which take 
QoS requirements into account, the setup of reservations becomes a mere trial-and- 
error approach. 
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A QoS driven routing algorithm has to consider the currently available capacity 
of a resource to avoid an immediate rejection of the reservation attempt and the QoS 
requirements of the reservation to find a route best-suited for this QoS. It should 
also consider the resource load after the routing decision to avoid using up the 
majority of resources on this route. 

Some of the problems to be solved with QoS routing are: how much state infor- 
mation should be exchanged among the routers; how often should this state infor- 
mation be updated; must there be a distinction between exterior and interior systems 
and if yes, how can it be made; is it possible to hide internal details of an autono- 
mous system; can the complexity of path computation be managed ? 

QoS routing is currently still in its infancy. At least in the Internet, its necessity, 
the principle ability to perform QoS routing, and the proposed approaches are cur- 
rently under highly controversial discussions. The ATM camp, on the other hand, 
designed PNNI which provides at least some QoS routing support. 

4.3 Pricing 

An important issue for the future success of distributed multimedia applications, 
and therefore of QoS methods themselves are the costs for any data transmission 
(i.e., with or without QoS). QoS methods have to take cost into account as an addi- 
tional (possible negotiable) parameter. However, as discussed in [ 16 ], most research 
has focused on specific issues; architectural issues have most often been neglected. 
The issues to be attacked are among many others: who pays for a service, and how 
is this indicated, especially if the receiver benefits from the transmitted data; can the 
user specify a limit on its expenditures; how can fairness be provided such that each 
receiver within a multicast session pays its share, how can payment cross a firewall, 
how can a department or group be charged instead of the overall company ? 

In addition to these aspects which apply to transmissions without QoS, further 
questions have to be answered in QoS provisioned systems, e.g.: how can resource 
consumption be “weighted” (e.g., delay vs. loss); what QoS do users accept for a 
specific price and which pricing schemes do they understand; how can fairness be 
provided such that all users - benefiting from a reservation made for a multicast 
transmission - share the costs in a fair manner ? 

Recently, some investigations on such questions have started which will hope- 
fully offer answers soon. 

4.4 Security 

Distributed multimedia applications require secure communication. Otherwise, 
integrated services networks will not find widespread usage by companies, e.g. 
video-conferences. This requires, in addition to suitable algorithms for encryption, 
also firewalls which provide appropriate mechanisms to support such data flows. 

Firewalls must be enhanced to allow audiovisual data flows to pass through, 
potentially after a check of their contents. Firewalls must also provide means for the 
reservation of resources. In the case that the flow’s packets are not simply forwarded 
but checked by some application code on the firewall, the resources to be reserved 
are not only network resources but local components as well. Hence, mechanisms 
such as CPU scheduling and memory management must be considered. 
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For some application scenarios, privacy should be provided, however, encryption 
of audiovisual data is too expensive or not necessary. For instance, a personal con- 
versation is most often not strictly confidential, we just want privacy such that no 
one can eavesdrop without significant effort. Thus, protocols should inhibit that 
someone can attach to such a stream without permission. Unfortunately, with IP 
multicast such a misuse is possible. 

4.5 Synchronization 

Much work has been spent on synchronization protocols and mechanisms for audio- 
visual data (e.g., [3]) and synchronization at the user interface is undoubtful an 
important issue. Yet, is it for most application scenarios (except, e.g., multi-user 
games and other competition-type applications) really such a difficult issue or can it 
be handled by well-known methods: Synchronized clocks (e.g., using NTP), inter- 
leaved streams, and buffer space (as long as it does not increase the delay much) ? 

4.6 Heterogeneity 

An important issue to be tackled by future systems is the support of heterogeneous 
systems considering heterogeneity with respect to different system technologies, 
e.g., ATM vs. Internet protocols, and with respect to varying system capabilities, 
e.g., broadband vs. narrowband networks and according clients. 

The integration of the various network infrastructures into a global, ubiquitous 
network capable of providing suitable support for multimedia communications must 
address, e.g., current Internet technology, ATM, and mobile systems. Efforts for the 
integration of ATM into the Internet world started recently (using ATM as a subnet- 
work with RSVP on top of it). If there will be native ATM applications, e.g., video- 
on-demand, then there is also the need for a ’side-by-side’ integration of ATM and 
Internet protocols, however, no advanced work on that is existing by now. 

Filtering mechanisms, which reduce the amount of transmitted and processed 
data, can support networks and end-systems with heterogeneous capacities. The 
basic mechanisms for this have been designed. Future work is necessary, for 
instance, to evaluate their performance characteristics and to study the possibility to 
use them with switched networks. Another interesting question is the ability to 
deploy such filters in active networks [18]. 

4.7 Scalability 

An important condition to be fulfilled by the methods designed for QoS provision- 
ing for shared and distributed components is that they must be scalable - they must 
remain usable even if they are applied on a very large scale. With respect to multi- 
media applications, e.g., multicast video conferences, scalability has at least two 
aspects: 

(1) scalability with respect to the number of participants in one application, 

(2) scalability with respect to the number of concurrent applications. 

The first requirement states that it must be possible to transmit a flow (distributed 
via multicast) to a potentially very large number of participants. This is, for 
instance, the case in transmissions from IETF meetings or prominent lectures. To 
fulfill this requirement, mechanisms for resource sharing among participants and for 
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the aggregation of reservations must be provided, furthermore, there should be no 
central component which has to process requests from new participants joining 
resp. old participants leaving such a conference. Based on their receiver-oriented 
reservation and flow joining concepts, RSVP and IP multicast support this require- 
ment. Using stream group concepts and receiver-initiated stream joining, ST-2+ 
[15] may support this as well, yet, we are not aware of any large scale experiences 
validating this. 

The second requirement demands that it should be possible to support many inde- 
pendent applications, and hence flows, - for example, thousands of video-confer- 
ences (probably with very few participants) and video-retrieval sessions. Therefore, 
the processing and storage effort per flow must be very small. The abilities of cur- 
rent protocols and architectures in this respect are not yet clear. We believe that it 
can be only shown by experiments because processing and storage overhead depend 
not only on architecture but on particular implementation as well. The soft state 
approach used by RSVP requires periodic message exchange per flow per receiver 
(potentially reduced by aggregation among receivers) to refresh the reservation and, 
hence, avoiding the loss of state. This needs transmission bandwidth and, perhaps 
more important, processing in the routers. Additionally, in order to be able to 
remove expired soft state, a timer must be kept per each receiver within each flow. 
While some of these can be aggregated (and efficient timer mechanisms such as 
timing wheels are known for quite a while), it can be expected that all these timers 
lead to some non-negligible overhead. Hard state approaches, on the other hand, 
avoid these problems since they neither require the permanent exchange of refresh 
messages nor timers per receiver (but per neighbor). However, they must keep the 
state all of the time and cannot, as soft state approaches may do, throw it away in 
case of lack of storage capacity. 

Which type of scalability is more important depends, on the predominant usage 
scenario. Currently, it seems to the authors that more attention has been given to the 
first issue: the scalability of one application. In future, small-sized applications will 
probably be more important, hence, more consideration should be given to the sec- 
ond issue: the scalability of concurrent applications. In general, more real-world 
experiments are necessary. 

4.8 Reservation in advance 

For several application scenarios, the model of immediate reservations, the only one 
offered by current reservation systems, is not fully appropriate. With this approach, 
resources are reserved when the application starts. Yet, for events where it is diffi- 
cult to find a date suitable for all participants, e.g., for video-conferences, the reser- 
vation must be set in advance if there is a noticeable blocking probability. Hence, 
mechanisms for Resource Reservation in Advance (ReRA) [23] are needed. By 
now, only preliminary results are available on this topic but neither complete end- 
to-end investigations nor large-scale experiences have been reported. There are sev- 
eral difficult issues which must be resolved before ReRA can find widespread sup- 
port. It might even be that the required overhead is too large to pay off (it might be 
more cost effective to reduce the blocking probability by over-provisioning 
resources). Despite a more complex resource management, some of the problems 
occurring in ReRA systems are state maintenance and failure handling. 
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All systems performing an advance reservation must keep the associated state 
information for a potentially long time. This must be stored in non-volatile memory 
to survive system failures and regular shutdowns, e.g., due to system maintenance. 
Alternatively, similar to the approach followed by RSVP, the reservation may be 
refreshed from time-to-time. As closer the actual usage time comes as more often 
are refresh messages send [7]. The drawback of this approach is that reservations 
which have been set might be lost during a system outage and cannot be reset 
because others have occupied the resources in the meantime. 

The treatment of failures occurring between the reservation setup and its use must 
differ from the steps taken to resolve errors of running applications. The reason is 
that the application which had lost its reservation is not running. So, which entity is 
to be notified and by which means? Further, potentially the failure situation can be 
cleared already before the resources are needed. Should the application be informed 
in such a case ? 

5 SUMMARY 

The provision of QoS in distributed systems has been an active resource area over 
the last years. Early work concentrated on deterministic guarantees exploiting pessi- 
mistic approaches by use of worst-case assumptions. Later, more optimistic models 
providing statistical and predictive services have been offered. 

The need for reservations was highly controversial a couple of years ago. Now, 
the concept of reservation-based QoS has found wide-spread acceptance, neverthe- 
less there are still * reservations about reservations* whose advocates consider reser- 
vations as too complex and propose adaptive mechanisms as overall solution. 
Neither reservation-based nor adaption-based QoS support would be necessary if 
the available system resources would become abundant. Yet, we believe that 
resource demand grows at least at the same pace as available resources, hence, res- 
ervation will be necessary for quality demanding applications and users in the 
future. 

Currently, system components are available, in the labs and partially deployed to 
’regular’ users, which are able to provide QoS support. An integrated end-to-end 
approach, from a data source (such as a disk in a video-server), via local and net- 
work resources (like CPU and transmission links), towards sinks at receivers (e.g., 
monitor) has not been settled yet. 

Various parts for a complete QoS infrastructure must be developed in the future, 
for instance, QoS routing, pricing, and security. Perhaps most important will be the 
verification of the suitability of the proposed mechanisms for the large-scale use: for 
(few) large multicast sessions with many receivers as well as for many small, con- 
current sessions. 
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Abstract 

The growing of computer networks and transmission capacity causes the possibil- 
ity of a rising amount of service offers in distributed systems. One of the CORBA- 
services is the trading service, which supports clients in searching for suitable 
services. 

This paper introduces an evaluation component for a CORBA trader. This com- 
ponent uses a service distance function to select an optimal service offer from a 
trader's database. A service distance function computes the distance between a 
service request and a service offer with regard to their service properties. The 
service with the minimal distance to the service request is the optimal service. 
Hence, existing methods for distance computation between vectors are used, and a 
rulework for computing the distance between service properties is developed. The 
resulting evaluation procedure is implemented in a CORBA trader using the dis- 
tributed platform Orbix. The implementation is compared with the classic evalua- 
tion mechanism of the used trader. Furthermore the various methods for distance 
computation are compared among themselves. 

Keywords 

CORBA; Trading service; Quality of service; Service distance. 



1 INTRODUCTION 

In a large distributed system many services are offered. To support a client in 
searching a special service a trader can be used. This trader has a service directory, 
which contains available services specified by a service type and service property 
values. If a client requests a service, the trader procures a convenient one. The 
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problem in this mechanism is that the process of selecting a service only matches 
the client's request against the service property values. There is no possibility to 
take into consideration quality of service aspects as defined in the quality of serv- 
ice basic framework [QoS 95]. Hence it follows, that two problems in the common 
trading mechanism arise: 

1. There is no possibility to identify an order of precedence on the fitting service 
offers. So the trader is able to procure a minimal suitable service whereas better 
services are registered in the trader’s service directory. 

2. If all service offers in the trader’s domain have a small deviation from the im- 
porter's specification, no service is procured. Nevertheless a little deviating 
service could satisfy the importer. 

This paper treats a modification of a trader's evaluation procedure. The modifi- 
cation allows the client to include quality aspects into its request. The trader now 
uses a set of service distance functions to calculate the distance between the service 
request and each service offer to investigate a ranking on the given service offers. 
Therefore, a service is viewed as a vector of properties. Analytic methods are used 
to calculate distances between such vectors. With respect to service quality a prop- 
erty can consist of several values with certain roles. Thus, to calculate a distance 
between these components, it was necessary to develop a new rulework. The serv- 
ice with minimal distance to the requested service is regarded as optimal service. 

The paper is structured as follows. In the second chapter an overview about 
service trading and quality effects is given. The trading process and service nota- 
tions are introduced. Furthermore the consideration of service quality leads to the 
concept of the service distance functions. The third chapter explains the concept of 
finding an optimal service in a trader's service directory. An overview about the 
implementation of the presented evaluation approach into a CORBA trader is 
given in the fourth chapter. Chapter five presents as well a comparison between the 
new evaluation component and the existing mechanism as a comparison between 
the used distance computation methods. Finally, the sixth chapter presents conclu- 
sions and tasks for further studies. 

2 SERVICE REQUEST VS SERVICE OFFER 

To explain the purpose of service distance functions, at first a short introduction 
into service notations and service trading is given. 

2.1 Service trading in CORBA 

A service is a function provided by an object at a computational interface [PSW 
96]. This function expresses a set of capabilities available at the interface. Such a 
service is an instance of a service type. For each service type there exists an affili- 
ated interface type and several noncomputational aspects called service proper- 
ties. Different services of the same service type may differ in their service proper- 
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ties. A service property is described as a (name, value) pair and is an instance of a 

service property type. 

A trader is a service procuring other services. For this purpose, a trader needs a 
service directory, which contains descriptions about all services available at the 
trader. A service description included in such a directory is called a service offer. 

An exporter, that is a server that wants to provide a service, can register this 
service within the service directory. The service is registered with exporter identi- 
fier, service interface identifier, service type description and service properties. 




A client using a trader to search a service is called importer [SPM 94]. It re- 
quests a service at the trader in specifying the service type and service properties. 
Therefore the importer chooses the operations SEARCH or SELECT. SEARCH 
brings about all suitable services, whereas SELECT brings about only one of them. 
Such specifications for example could be made by a service description language 
[PM 94]. The choice of suitable services at the trader is made by matching service 
type and service properties with every service offer. The result of a service import 
is an interface identifier. Now, the importer can directly contact the server that has 
exported the service. This trading process is shown in figure 1. 

2.2 Quality of service and service properties 

The described trading mechanism only tolerates single values for each service 
property. These values are matched against values of the service offer. A single 
demanded value is either fulfilled or not. This concept is insufficient for many ap- 
plications. Many services like video conferencing and interactive applications need 
a consideration of quality aspects. The quality of service could be taken into ac- 
count by formulating quality characteristics as service properties. Quality charac- 
teristics are e.g. throughput, transmission delay or availability [Th 95]. Now, an 
importer needs to specify more than one value, namely a target, a lower bound 
and an upper bound on such a characteristic to formulate its wishes and limits, see 
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figure 2. All these values are components of a quality of service parameter, so they 
all are needed to express quality [QoS 95]. Furthermore the importer must be al- 
lowed to specify the preference of every characteristic, so that the trader knows 
what characteristics are to be dealt with priority. Because of the arising complex 
structures of service properties, normal matching no longer can be used. 

Service Properties 

Service Request: r = fry, ..., ) with Service Offer o = (ou Om ) with 

Service Request Property n : Service Offer Property oi : 

n- { Target t oi= { Upper Bound u 

Upper Bound u Lower Bound 1 

Lower Bound 1 } 

Preference p 

} 

Figure 2 Service Property Structure 

A number of distance functions on vectors are well known in analysis, especially 
maximum metric. Euclidean metric and Manhattan metric. Furthermore methods in 
fuzzy set theory and the analytic hierarchy process provide approaches suitable for 
the distance computing on vectors. But there is no method to compute the distance 
between single components, because they are records of values with different 
roles. So, it was necessary to develop a distance function on service property rec- 
ords. This distance function is presented in the next chapter, just as a short over- 
view of known distance functions on vectors. 



3 SERVICE DISTANCE FUNCTION 

To compute the distance between service vectors, two steps are necessary. The first 
step is to compute the distance between the components of both vectors, the serv- 
ice property records. This step is described in section 3.1. The result is a vector of 
differences. In the second step, these differences must be combined to the distance 
between vectors. In section 3.2 some methods are presented to achieve this. Sec- 
tion 3.3 presents a short comparison of the presented service distance functions. 

3.1 Service property record distance 

As described in chapter two, a service request property with quality consideration 
in our example consists of four values with the roles target, upper bound, lower 
bound and preference. A service offer property consists of a lower bound and an 
upper bound. So, it is impossible to compute a simple difference between both 
structures. Therefore, it was necessary to draw up rules for every possible combi- 
nation of values. 
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The importer is allowed to specify each combination of target and bounds. To 
simplify the evaluation, in the specifying process either both or no bounds are oc- 
cupied. Not occupied components have the value undefined. Likewise the exporter 
can specify only one or both bounds. Service offer vector and service request vec- 
tor need not have equal size and contain equal properties, so oi only means the 
property with the same name as n . In this paper only a short insight into the rule- 
work is given. The complete rulework is explained in [Th 96]. 

• If the service request property n only defines a target, the difference is zero if 
the value is within the bounds of the affiliated service offer property oi . Out- 
side the bounds the difference to the corresponding bound must be computed: 
if ri .t 1 Md n .u = 1 and Oi.u ^ JL then 
if Oi .1 < n .t < Oi .u 
then dc(n, oi) = 0 
else if Oi .u < n .t 
then dc(ri ^ Oi) = H .t - Oi .u 
dse dc(n ,oi) = Oi .1 - n .t 

The rules for the cases that only bounds or bounds and a target are specified, are 
treated similar. Furthermore there are other problems that must be considered, e.g. 
properties could be specified in a non-numerical format or in a probabilistic way. 
At last, the resulted difference must be weighted with the importer specified 
weights to consider the importance of a property. The result is a weighted com- 
ponent distance dwc- 

dwc(ri ,oi) = n .p ^ ddn , Oi ) 

The whole set of rules allows to compute the distances in all components of the 
service request vector. The resulting differences could be put together in a differ- 
ence vector d = fJ; , ..., dn ) with di = dwcfn , oi ) for i = 1, ..., n. In the next step all 
these values di are to be combined to the difference between the service vectors. 

3.2 Service property vector distance 

The idea of a vector distance function dv is to compute a distance between vectors 
by combining the individual component differences. In analysis there are a few 
metrics which can be employed on such vectors. In general, an analytic metric for 
n > 0 is defined as follows: 

dv(( xi,...,xm),( yj,...,ym)):= 

In practice, the relevant cases are n = 1, 2 and infinity. In these cases, the metrics 
are called Manhattan metric. Euclidean metric and maximum metric. The optimal 
service offer can be found by minimising the distance dv. Beside the mathematical 
functions to compute the distance between vectors, in practice there are other 
methods to find out an optimal service: 
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• Fuzzy set theory [Zi 91] 

• Analytic hierarchy process (AHP) [Sa 80], [DP 94] 

• Additive and multiplicative model [Be 90] 

A description of these methods can be found in [Th 96]. 

3.3 Comparison 

In the previous sections service distance functions dwc and dv were presented. 
There is no other function to compare with dwc , because the property records have 
a new structure. So the service ability of dwc is to be examined in practice. For dv, 
several methods are presented. The additive model needs not to be considered, be- 
cause it is equal to Manhattan metric. Table 1 gives a short overview about com- 
putation complexity, expected result precision and implementation easiness for all 
vector difference computing methods. 



Table 1 Overview about the presented methods 





metrics 


fuzzy set theory AHP 


multiplicative model 


complexity 


+ 


+ 


0 


precision 


+ 


+ ++ 


+ 


implementation 


+ 


+ 


+ 



Because of the easy implementation possibilities of all methods except the ana- 
lytic hierarchy process, the best solution is an integrated distance computation 
mechanism with choice of the distance function by the importer. 



4 IMPLEMENTATION OF THE EVALUATION COMPONENT 

In this chapter, concepts are presented for implementing the trader evaluation 
component in C++. The evaluation component is integrated in an existing CORBA 
trader [Zl 96] of the distributed platform Orbix [ORBIX]. Different importers 
could have different meanings about an optimal service. Therefore, in the evalua- 
tion component every combination of a distance function with both, multiplicative 
and exponential weightings is possible. 

The importer must specify the service request as before, only additionally it can 
specify more values on a service property. Furthermore, the importer must choose 
a service distance function and a weighting mechanism. Hence, two types are de- 
fined, distance_type and preference_type. The first type includes the 
methods for computing a service property vector distance as presented in chapter 
3.2, the second type contains a set of weighting mechanisms. Fuzzy set theory op- 
timisation and the additive model can be viewed as special cases of maximum met- 
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ric respectively Manhattan metric. Because every combination of distance func- 
tions with preference functions is allowed, these types do not need to be consid- 
ered. To be consistent with the trading standard, the service properties can not be 
transmitted to the trader as vector, but must be transformed in policies. Within the 
trader, this transformation must be annulated. 



/* The class qosConstraints describes the service request properties 
*/ 

class qosConstraints 

{ private: struct_qos_specif ication *qosSpecif ication 
public : void set_qosSpecif ication ( 

const iwt_types : :ConstraintSpecTypeSc matchingConstraints, 
const iwt_types :: Prefer enceSpecTypeSc selectionPreference) ; 



struct_qos_searchVector *return_vector { ) ; 

In- 
struct struct_qos_specif ication 
{ distance_type distance_function; 
preference_type preference_function; 
struct_qos_searchVector *qos_searchVector ; 

}; 

Figure 3 Class qosConstraints for a service request 

Because Orbix and the used trader are object oriented, the quality of a service 
request, i.e. the service properties, are seen as an object of the class qosCon- 
straints, see figure 3. The internal state qosSpecif ication is a vector 
containing the desired distance and preference function as well as a vector of 
s true t_qos_searchVec tor. For each service request property, this vector 
includes a record of target, upper bound, lower bound and preference. The public 
function set__qosSpecif ication serves for covering the qosSpecif ica- 
tion with the specified matching constraints. The specification is contained in 
the variable matchingConstraints. selectionPreference contains 
the preferences on the properties specified in matchingConstraints. Both 
are defined in the existing trader. Furthermore, functions must be implemented to 
get the registered qosSpecif ication. More work is not needed on an object 
for a service request vector. 

/* The class service__qos describes the service properties in a service offer 
*/ 

class service_qos 

{ private: struct_qos_of ferVector *qos_of ferVector ; 
public : void set__qosOf ferVector ( 

const iwt^types : : PropertyValueListTypeSc spv, 
const iwt_types :: Proper tyValueListTypeSc sopv) ; 



double compute_distance (s true t_qos_searchVec tor * sear chVec tor, 
distance_type distance_function, 
preference_type preference_function) ; 

}; 

Figure 4 Class service__qos for a service offer 



Likewise the property specification is seen as an object. For service request and 
service offer different objects are necessary, because a service provider can specify 
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fewer values on a property. So, the internal state qos_of f erVector of an ob- 
ject for service offer properties is a vector which contains a record consisting of 
upper and lower bound for each service offer property. A function 
set_qos_off erVector is needed to cover the vector with the exporter's 
service property and service offer property values. Then, the distance to a service 
request specification is to be computed using the function compute_distance. 
This function realises the distance functions described in chapter three. The class 
service__qos for the service offer properties is shown in figure 4. 

The described objects are implemented and integrated into the CORBA trader. In 
the trader, all service offers are stored into a service directory as objects of class 
ServiceTableltem. Such an object generally contains a property value list. 
Instead of this, at the service export now an object service_qos for each serv- 
ice is generated. At a service import, the presented matching constraints are trans- 
formed into an object qosConstraints. This object is passed to the service di- 
rectory, and then to the service_qos of each ServiceTableltem. Within 
this object, the service distance between the service request and the affiliated serv- 
ice offer is computed. All suitable service offers are collected in a list which is 
sorted by the computed distance. So, the first entry is the optimal service. 

5 ASSESSMENT OF THE EVALUATION COMPONENT 

To assess the evaluation component, a comparison with the classic trader will be 
necessary. Furthermore, the different distance functions should be compared with 
each other. For this purpose, two comparisons are made. First, the evaluation times 
of all methods are compared. Subsequently, a comparison of the import results is 
given. 




Figures The measure points 



To investigate the trader’s evaluation time, four measure points have been estab- 
lished. These points are shown in figure 5. Nothing happens between A and B in 
the classic trader. In the new trader the transformation of the matching constraints 
into a service request property vector is made there. The evaluation process takes 
place between B and C. Between C and D only a copy of the resulted service offer 
is made in both traders. The only exception is the AHP. At this method, pairwise 
comparisons between all service offers are necessary. Therefore, after passing 
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point C the matrices for pairwise comparison must be evaluated. To do so, the time 
spans AB, BC and CD are measured. 

In the following, all service offers have the same service type and the same 
service properties. The service property values are chosen by chance. Furthermore 
the service request has the same service type and a subset of the properties of the 
service offers. 




Figure 6 Time of the overall evaluation process 

Figure 6 shows the overall evaluation time the trader needs depending on the 
number of service offers with correct service type in the trader’s database, i.e. AD, 
The service request is made with five of the service offers’ properties. All evalua- 
tion mechanisms show an exponential ascent in the evaluation time. The reason is 
the implementation of sequences in Orbix. All suitable services are collected in a 
sequence of the type serviceOf ferDetailType. If a suitable service is 
found, a new sequence with an increased length is generated. Then, the content of 
the old sequence must be copied into the new one. With an increasing number of 
services, the information which has to be copied increases as well, resulting in an 
exponential ascend of evaluation time. On the same reason the classic trader is 
faster than the new one, because there is a lower amount of information that must 
be copied. 

The behaviour of the AHP is slightly different from that of the other distance 
functions. To explain that phenomenon it is necessary to split the evaluation time 
into the times AC and CD. AB needs not to be considered individual, as this is only 
one millisecond on average. Figure 7 shows the time between C and D. At the use 
of the AHP at CD the pairwise comparison takes place. For each service request 
property a matrix is generated. For each new service offer, the size of all matrices 
increases, resulting in an exponential ascend. The other distance functions and the 
classic trader only make a copy of the resulted service offers; in these cases the 
time increases constantly. 
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Figure 7 Time after the search in the service directory 

Time behaviour of the classic trader is more suitable than the new one’s, but this 
results by the implementation of the Orbix sequences. By implementing own se- 
quences, this disadvantage becomes lost. 

Now the result of the service import should be examined. Ten service offers with 
the correct service type and ten service properties are exported. These services are 
imported and the distance to each service is considered. The sum of the distances is 
standardised to one, to make possible a comparison between the distance functions. 




Figure 8 Distances to all imported services 

Figure 8 shows the distance to each service offer for all distance functions and 
the classic trader by specifying a service request with ten properties. The figure 
shows a similar behaviour of the metrics. The multiplicative model shows a more 
extreme behaviour. The more suitable services are very well evaluated and with 
only small differences between them. That results from the fact that large differ- 
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ences in service properties are weighted stronger than low differences. The less 
suitable services are evaluated very disadvantageous and with large differences. 
The AHP evaluates the best service offer very good, the other service offers are 
valued very bad. The reason is the comparison strategy used. The classic trader 
values all services equally, the first service found is selected. It should be men- 
tioned that the service order resulting from the use of a distance function is de- 
pending on that function. 

The behaviour of the distance functions leads to the idea of extending the opera- 
tors SEARCH and SELECT. The importer could specify a distance of the interval 
[0, 1]. Only those service offers with a relative distance lower than the importer’s 
distance parameter are presented. Such a variation of the importer’s operations is 
not possible with the classic trader. 

Altogether the new evaluation component has an advantage compared to the 
classic trader. But in further investigations the suitability of the analytic hierarchy 
process appeared as very low. Therefore the pairwise comparison of the analytic 
hierarchy process should be revised. 



6 CONCLUSIONS 

This paper has presented an approach to formulate and evaluate service properties 
with respect to quality. For that purpose services were viewed as vectors, so it was 
possible to compute the distances between a service request and each service offer. 
An optimal service offer has a minimal distance to the service request. Further- 
more, aspects are presented to implement the service distance computing method 
in an Orbix trader. The implementation was tested and the new evaluation mecha- 
nism was compared with the classic trader. Additional, a comparison between the 
distance functions was given. 

The result of this paper is an evaluation mechanism for distance computing be- 
tween services. This rulework is more flexible and more importer oriented than 
common selection mechanisms, because it allows the importer on the one hand to 
specify the quality of its properties. On the other hand it allows to express its inter- 
pretation of an optimal service. So the importer gets better services. Because the 
disadvantage of distance functions in evaluation time is caused by the implemen- 
tation of Orbix, the evaluation component altogether is more suitable than the old 
mechanism. Furthermore an extended importer operation SEARCH or SELECT 
should be implemented using service distance functions. 

The future tasks are to enhance the rulework by considering threshold on service 
properties and enabling the description of all service property values as probabilis- 
tic or statistic. Another point of interest is the distinction between static and dy- 
namic properties. Further work has to be done on optimising the trader’s time be- 
haviour, e.g. by transforming non-numerical service properties into a numerical 
format at the importer. Furthermore it is necessary to modify the pairwise compari- 
son in the analytic hierarchy process. Otherwise this method is useless. 
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Abstract 

This paper gives an overview of the mechanisms that currently specified APIs 
(for Native ATM and for RSVP) provide to applications for the purpose of 
controlling QoS parameters. It compares the abstractions they provide with 
respect to application needs and modern operating system practices. Fur- 
thermore, it discusses what extensions or modifications would be desirable in 
future APIs. 
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1 INTRODUCTION 

After an introduction to general aspects of QoS and APIs, we describe in 
section 2 how several APIs for network architectures with QoS support provide 
control over QoS parameters, how they present signaling mechanisms to the 
application, and how they integrate connection establishment with reservation 
setup. In section 3, we examine if they meet application needs and how they 
integrate with advanced operating system concepts. Finally, section 4 proposes 
directions in which QoS-aware APIs should evolve in the future. 

1.1 What is QoS ? 

Quality of Service (QoS) concerns are applicable at all layers of a proto- 
col stack, and depending on the specific protocols, there may be an explicit 
transformation of the service guarantees as the user information transits the 
protocol stack. QoS concepts can be applied where there are performance as- 
pects of interprocess communication, even when there is no external network. 
Most humans interacting with computers expect some sort of response within 
a reasonable time and this provides what one might call a user level QoS 

Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
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constraint on system performance. In general there may be multiple other 
dimensions to QoS e.g. reliability, security, loss, cost, etc. 

User level QoS issues are becoming increasingly important as people rely 
more on computer interaction as a fundamental daily activity. One measure of 
this is in terms of the economic consequences of QoS failures. This is not just a 
question of customer relations for the service providers. Performance failures 
of consumer services may lead to legal or regulatory consequences. In the 
context of a Global Information Infrastructure, QoS must be parameterized 
and mechanisms for allocations and parameter degradation are required for 
deployment. For some applications, there are guidelines already available (see 
e.g. [1] for voice services), for others, the user level QoS requirements need to 
be clarified first. 

QoS guarantees are most valuable when applied end-to-end. Unfortunately 
this is also the most complex case, since it requires common QoS concepts to 
be available across a variety of equipments, perhaps within different jurisdic- 
tions. 

QoS concerns might arise wherever there are multiple independent requests 
for a constrained resource, (e.g. a multiplexer or scheduling function). This is 
not just a problem for network equipment - it applies also to the software ap- 
plications that can introduce degradations into the end-to-end service. There 
have been some efforts in multi-threaded and distributed operating systems to 
provide support for QoS notions (see e.g. [2]) and also in terms of QoS support 
for higher layer constructs in the information infrastructure (e.g. Object Re- 
source Brokers [3]). The widest consensus on QoS notions seems to have been 
reached on the communications aspects, here we have selected three APIs that 
are specifically relevant in that context, and so we are primarily concerned 
with QoS aspects such as loss and delay. 

1.2 APIs in QoS Architecture 

Because networks are becoming available which provide native support for 
QoS concepts, it is appropriate to consider related issues such as the mecha- 
nisms by which applications can best utilize these network based QoS concepts 
in support of user level QoS requirements. For the majority of software based 
network applications, the application developers make use of such network 
based QoS guarantees through some form of Application Programming Inter- 
face (API). 

APIs with QoS concepts are required at various interfaces within a larger 
system or application wide QoS Architecture. Various QoS architectures and 
other abstractions have been proposed in the literature (see e.g. [4, 5, 6]). [7] 
proposes that QoS architecture concepts are required to span OSI layers 1-7 
and also addresses aspects such as: 

• orchestration of multiple information fiows with related QoS bounds (e.g. 

relative jitter between component media streams of an integrated service). 
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• QoS negotiation, renegotiation and degradation indications, 

• reservation of end system and network resources, 

• policing of these resources, 

• connection admission policies, 

• resource control, monitoring and regulation for support of distributed in- 
tegrated service (e.g. multimedia) systems 

[8] arranges the elements in a pipeline in order to allocate delay budgets to 
the various components in the overall system. One of the interesting aspects of 
this specific implementation was that, although deterministic guarantees de- 
rived from queuing models (e.g. as provided by ATM switches) were desired, 
the host’s I/O subsystem was not able to provide deterministic delay guar- 
antees, and so only statistical guarantees could be provided end-to-end. QoS 
guarantees of a statistical nature (rather than deterministic) may be impor- 
tant until the software environment can also support deterministic guarantees. 



2 API CASE STUDIES 

In this paper we consider several APIs which provide QoS guarantees for 
network services. Our intent here is not to provide an exhaustive list of APIs 
which provide some form of QoS support. In selecting APIs we looked for 
APIs for popular operating systems, which were clearly specified, and had 
some implementations available to provide the basis for further comparisons. 
Our preference has been to consider APIs which support QoS concepts which 
are well defined, e.g., ATM or the lETF’s Integrated Services model. The 
APIs we compare in the later sections of the paper are: 

• RSVP 

• Native ATM 

• Arequipa 

Code examples for some cases are available from ftp://lrcftp.epfl.ch/ 
pub/people/almesber/iwqos97 

2.1 RSVP 

The Internet Engineering Task Force (IETF) has defined an architecture for 
providing integrated services on the Internet [9]. The protocol used to estab- 
lish and maintain reservations is called the “l^source reSerVation Protocol” 
(RSVP, [10]). 

There is currently only one published API for RSVP: the API defined by 
ISI and Sun Microsystems (SMI) [11] used in the RSVP implementations by 
ISI and by SMI.* 

Since the services provided by and used with RSVP and the API are both 



ftp : //ftp . isi . edu/rsvp/release and ftp : //playground . sun . com/pub/rsvp 
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still work in progress, the respective current versions may differ slightly from 
what is described in this paper. 

RSVP carries traffic descriptions (called TSpecs), information about the 
network (called Adspecs), and the actual reservation parameters in flow specs 
(see [12] for details). Flows are selected using filter specs. The ISI/SMI RSVP 
API provides access to exactly the data conveyed in RSVP messages, i.e. for 
each flow, each sender can provide a TSpec and an Adspec, and each receiver 
can provide filter specs and flow specs. The numerical values are identical to 
the values contained in the RSVP messages. Additionally, placeholders for 
extensions such as exphcit packet format templates and policy information 
are defined. 

While there is no abstraction for the reservation information, the API hides 
protocol activities like continuous refreshes from the application. It does how- 
ever generate asynchronous notifications in the event of changes in the reser- 
vation state, e.g. if a reservation succeeds, fails, or changes. 

The API design follows the design of RSVP in that the mechanisms for 
reservation setup and for the actual flow setup are independent. Note that 
this can be used to set up reservations on behalf of other programs, which is 
nicely illustrated by the tkrsvp application (ISI). 



2.2 Native ATM 

APIs for “native ATM” allow applications to establish ATM connections and 
to control the QoS parameters that are chosen for the connections. Native 
ATM APIs normally don’t distinguish between the actual reservation and 
connection establishment, because a connection and the corresponding reser- 
vation are set up at the same time in the ATM network too. Furthermore, as 
of UNI 3.1 and UNI 4.0 ([13, 14]), connection parameters can’t be modified 
once the connection is established. A connection’s QoS therefore remains fixed 
for its entire lifetime. 



(a) Semantic description 

The document [15] specifies the semantic definition of ATM-specific services 
that are available to software programs and hardware residing in devices on 
the user side of the ATM User-Network Interface. The ATM environment pro- 
vides new services to the application developer. They allow enhancements in 
performance and specification of network characteristics. Such ATM-specific 
services are denoted by the term “Native ATM Services” . 

“Semantic” means that the document describes the services in a way that is 
independent of any programming language or operating system environment. 
Semantic specifications for generic services define various aspects of the inter- 
face to those imderlying services. Here we will focus on the call establishment. 
This is the step where the Quality of Service necessary for the user applica- 
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tion are defined. The current specification is based on version 3.1 of the UNI 
([13]). 



(b) WinSock 2 

The ATM Forum reviewed the WinSock 2 ATM annex [16, 17] and a mapping 
from this syntax to the Semantic description [18]. This API currently supports 
only AAL5 and user defined AAL types, although it had been announced that 
there would be future upgrades to support other AAL types (e.g. AALl) as 
well as extensions to support UNI 4.0 signaling as the semantic specification is 
updated. The WinSock 2 API does not support management plane primitives, 
but does provide other mechanisms to access this information. 

The QoS structure used in WinSock 2 is contained in the ProviderSpecif ic . 
buf field of the QoS Structure. Note that use of this ATM-specific structure 
is optional by WinSock 2 clients, but if provided, it takes precedence over any 
more generic FLOWSPEC structure. The protocol specific QoS Structure for 
ATM is a concatenation of the Q.2931 Information Elements. 

The basic QoS mechanism in WinSock 2 descends from the flow specifi- 
cation ([19]). Flow specs describe a set of characteristics about a proposed 
unidirectional flow through the network. Flowspecs provide parameters to in- 
dicate what level of service is required and provide a feedback mechanism for 
applications to use in adapting to network conditions. An application may 
establish its QoS requirements at any time up to and including at the time 
a connection is established. If the connect operation fails because of limited 
resources an error indication is given, and the application may scale down its 
service request and try again or simply give up. 

After every connection attempt, transport providers update the associated 
flow spec structures in order to indicate the existing network conditions. Ap- 
plications expect to be able to use this information about current network 
conditions to guide their use of the network, including any subsequent QoS 
requests. 

WinSock 2 also considers that, even after a flow is established, conditions 
in the network may change or one of the communicating parties may invoke 
a QoS renegotiation which results in a reduction (or increase) in the available 
service level. A notification mechanism is included which utilizes the usual 
WinSock notification techniques to indicate to the application that QoS levels 
have changed. If the updated level of service is not acceptable, the application 
may adjust itself to accommodate it, attempt to renegotiate QoS, or close the 
socket. Note that support for the functionality described in this paragraph is 
implementation-specific and is not provided by the current ATM extension. 

The flow specs proposed for WinSock 2 divide QoS characteristics into the 
following general areas: 

• Source traffic description; 

• Latency (delay and delay variation bounds); 
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• Level of service guarantee (best effort, controlled load, predictive service, 
or (deterministic) guaranteed service); 

• Cost (this is a placeholder); 

• Provider-specific parameters, e.g. ATM QoS definitions 

QoS templates can be established for well known media flows e.g. H.323, 
G.711. 

It is up to each service provider to determine the appropriate values for each 
element in the QoS structure, as well as any protocol or media-dependent QoS 
extensions. A default flow spec (best effort) is associated with each eligible 
socket at the time it is created. 

(c) X/Open 

Based on the semantic description [15], ATM extensions have been specified 
for the XTI, XSockets, and DLPI APIs defined by X/Open. The syntax in- 
stantiation of the semantic description to XTI is defined in [20]. The XSockets 
extensions, which are derived from the corresponding XTI extensions, are de- 
fined in [21]. Both APIs represent connection attributes as (socket) options, 
which are accessed with the option handling mechanisms of the respective 
API (t.optmgmtO, options with t.connectO . . ., setsockopt, etc.). 

The definition of an instantiation of the Native ATM Services to the Data 
Link Provider Interface is currently a work item of the S A A/ API work group 
of the ATM Forum, per X/Open request. Most of the ATM connection at- 
tributes can be queried using DL_INF0JIEQ and DL_INFO_ACK. Other connection 
attributes are either provided in DLPI primitives exchanged at connection es- 
tablishment time by the DLS user, or they are returned at bind or connection 
time by the DLS provider. 

2.3 Arequipa 

Arequipa [22, 23] is a mechanism which aims to allow TCP/IP applications 
the use of QoS as supported by ATM networks. Arequipa has been developed 
at EPFL since 1995 and it has been implemented on Linux. 

Arequipa allows applications to establish direct point-to-point end-to-end 
ATM connections with given QoS at the link level. These connections are 
used exclusively by the applications that requested them. After setup of the 
Arequipa connection (i.e. the ATM SVC that is used for Arequipa), the ap- 
plications can use the standard TCP/IP protocol suite (and its APIs) to 
exchange data. 

Arequipa requires that communicating hosts can reach each other over both 
the Internet and an ATM network. Its scope can be extended to include hosts 
without direct ATM connectivity by the use of application-level gateways. 

For practical reasons, Arequipa is based on the native ATM API described 
in [24]. Arequipa uses a pre-defined SAP (Service Access Point) and - as far 
as they are invoked firom user mode - it performs all operations in blocking 
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mode. It also handles acceptance of incoming connections transparently for 
the application. Furthermore, future versions of Arequipa may not require 
a user-provided ATM address and query an address resolution service (e.g. 
NHRP [25] or MPOA [26]) instead. 

Arequipa can therefore be characterized as providing full access to the QoS 
capabilities of the underlying native ATM stack, but as restricting the choice 
of endpoints. 



3 EVALUATION 

In the following sections, we examine how the QoS and other abstractions 
provided by the APIs meet application needs and how (if) they integrate 
with advanced operating system concepts. 

3.1 Level of abstraction 

All of the APIs we reviewed stay very close to the service interface the network 
provides: while they hide basic protocol mechanisms (e.g. retransmissions) 
from the applications, they (with the exception of Arequipa) are very careful 
not to miss a single opportunity to notify the application about any change 
in the overall reservation state. Furthermore, all of the APIs provide exactly 
the semantics and the syntax of the traffic characterization and reservation 
mechanisms of the respective architecture. 

Access to most aspects of the protocol state has the disadvantage that 
existing interfaces need to be stretched very far, either by the introduction of 
many new primitives (e.g. RSVP, WinSock 2) or by overloading some functions 
(e.g. X/Open). Given that most applications only use a very small fraction 
of the available functionality, access to some simplified API is desirable. For 
RSVP, the tkrsvp package’^ offers a simplified API for Tk/Tcl programs. 

The lack of abstraction in the QoS parameters raises several problems: 

• API users frequently have difficulties characterizing the traffic their appli- 
cations generate in the terminology and in the level of detail used by the 
network architecture. 

• translation of QoS needs of the application to the interface provided by the 
API highly depends on the reservation architecture, i.e. ATM-based APIs 
expect all counts in cells, while RSVP APIs count in bytes and are also 
concerned with packet sizes and slack terms (see also [27] and [28]). 

3.2 Advanced operating system concepts 

QoS support in operating systems is considered primarily from the perspec- 
tives of real time support and concurrency. However, recent work in object 

•ftp : /ftp . isi . edu//rsvp/release/app* tkrsvp . rel4 . lal . tar . Z 
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based services may also be relevant as these become supported by the operat- 
ing system. It has been proposed [3] that the following factors be considered 
in development of QoS support for real-time object based services: 

1. policies and mechanisms for specifying end-to-end applications QoS re- 
quirements 

2. operating system and network 

3. communication protocols 

4. request demultiplexing and dispatching 

5. memory management, presentation layer 

(a) Real-time support 

Real-time operating system support is required for software applications which 
require guaranteed bounds on their execution time. Like the network QoS con- 
cept of delay bounds, the delay bounds that apply to software execution times 
may be explicit or implicit, statistical or deterministic. Such delay bounds can 
be used to determine whether an application can be run successfully, with the 
resources available. This decision on whether or not to execute the application 
can be considered as analogous to the Connection Admission control (CAC) 
function found in networks with resource reservations. 

The software implementations supporting the APIs typically attempt to 
minimize the delay between the I/O device and the API. However, the APIs we 
considered do not provide means to extend the guarantees to this part of the 
end-to-end path. [29, 30, 31] discuss more advanced architectural approaches. 

(b) Concurrency 

For QoS-aware network applications, multi-tasking or multi-threading (i.e. 
concurrent execution of programs) are affected by the API in the following 
areas: 

• processing of the application data, and 

• control operations 

Data processing can be parallelized if the concurrent threads can either work 
on distinct parts of the data stream or if elements of the data stream have 
no sequential inter-dependencies, so any thread can handle a new element 
whenever it is ready. The latter case is trivial, so all APIs we considered 
support it. 

Automatic demultiplexing of data without involving the application is more 
difficult: While all APIs allow an application to open several flows and to per- 
form operations on them, only RSVP can perform reservations for more than 
a single flow with one request. None of the APIs allow marking of data inside 
a single flow such that the operating system at the receiver can distribute the 
data directly to the thread that is processing it. 

Most flexibility for parallelizing control operations is reached if no extra 
serialization of events is enforced by the API. With the exception of Arequipa, 




Quality of service (QoS) in communication APIs 



245 



all the APIs we considered inflict serialization upon the applications only in 
negligible ways (e.g. the ATM APIs serialize incoming connections on the 
end point describing the service access point, but allow further processing to 
continue in parallel). 



3.3 Legacy applications with implicit QoS requirements 

In some cases, the data flow that is supported by the service quality guaran- 
tee does not need to pass through the same API that was used to specify the 
QoS level. One example of this approach is where legacy applications that are 
not QoS aware, but have implicit QoS requirements, are supported by their 
existing data plane API, but an additional API is used for management plane 
access to administratively control the QoS service provided to that applica- 
tion, see figure 1 (e.g. [32]). Default QoS insertion need not be a static decision. 
The QoS parameter values could be determined dynamically by monitoring 
the application’s usage pattern, etc. 




Figure 1 Management plane API supporting legacy applications with im- 
plicit QoS guarantees 



4 DIRECTIONS FOR FUTURE WORK 

The diversity of API syntaxes can be explained by the different operating 
systems within which they are bound. The diversity of API semantics can be 
explained in part by the diversity of reservation protocols (e.g. soft state vs. 
hard state) and also by the level of abstraction of the interface in question. 
Three main directions for future work are seen: 

• Unification of QoS semantics at the API for different architectures 

• Extensions to the semantics of the APIs to cover data plane redirection 

• Extensions of the QoS guarantees provided on external communications 
links to internal interprocess communications mechanisms 

• Other software abstractions of QoS 
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4.1 Unification 

Given that all the reservation services aim to support rather similar types 
of traffic (e.g. video encoded with MPEG-1, MPEG-2, or H.261), one could 
expect that a common set of parameters exists that the API (or an API 
layered on top of it) could translate to the set of parameters suitable for the 
reservation mechanism. 

This is in sharp contrast to the current situation (see section 3.1), where 
APIs for distinct reservation architectures express QoS parameter in very 
different ways - even if they share the same operating system architecture. 

The general QoS interface found in [16] and simplified RSVP API proposed 
in [33] are perhaps indicative for a trend towards the development of more 
abstract and unified APIs. 

4.2 Data plane redirection 

While most of the work on QoS Architectures to support multimedia services 
assume a general processor as an endpoint, it is also necessary to consider 
those applications where the data plane does not need to pass through the 
processor, but is destined for some hardware device - e.g. an MPEG codec. 
In many continuous media applications, the data stream from the network 
interface simply needs to be redirected towards the relevant I/O peripherals 
(e.g. the sound card or the display card). In this case, the data plane may 
have no appearance required at the API, and a management plane API may 
suffice. The ATM Forum S A A/ API group is currently considering extensions 
of this type to the semantic API specification. The use of peripheral buses 
such as PCI [34] or PC-ATM [35] provide support for such approaches. Note 
that such buses can often be arranged in a hierarchical fashion which may 
complicate the data transfer. A simple switch abstraction may be the best 
mechanism to mask this potential complexity for the application while still 
supporting a QoS guarantee over this portion of the data transfer. Desk Area 
Networks [36] are one example of such an architectural approach. 




Figure 2 Data plane redirection 

Conventional computing performance is measured in terms of processing 
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power, however such performance measures are not necessarily appropriate 
for distributed applications such as those shown in figure 2, where not all the 
end points of a data fiow are CPUs. Even I/O performance metrics (e.g. [37]) 
still assume a processor dependent component, which is not relevant to the 
network centric computing model of figure 2. 

4.3 QoS for IPC 

The APIs discussed in this paper provided mechanisms for QoS support over 
external interfaces. Mechanisms for the support of QoS over internal inter- 
faces is an area of ongoing study topic for operating systems, particularly 
distributed operating systems and those intended to support real time mul- 
timedia applications (see e.g. [29, 30, 2]) This case is made difficult by the 
variety of different scheduling mechanism that need to be considered within 
the QoS architecture - not just the I/O devices, but also the buffer manage- 
ment, operating system processes etc. need to be considered. 

4.4 Is an API always the answer? 

APIs are not the only programming abstraction that can be used to provide 
support to applications that need QoS support. One could consider also the 
impact of QoS extensions in other programming abstractions such as the file 
system or elsewhere in the memory hierarchy. Most file systems rely primarily 
on semantics such as open, close, read, write which do not have any temporal 
basis. Extensions to file systems to support other semantics such as start /play, 
stop, pause, fast forward, rewind may also be required [38] to deal with con- 
tinuous media types. The semantics of these operations may have temporal 
aspects that would need to be related to QoS support in other parts of the 
operating system. 

One could also consider language constructs to support the use of QoS. QoS 
concepts are concerned with guarantees of performance. As such it might be 
reasonable to consider such guarantees in the light of language mechanisms 
to specify operational performance. One might reasonably consider QoS ex- 
tensions to program specifications such as the package definitions in Ada or 
the Contracts of Eiffel. 



5 CONCLUSION 

We have briefly summarized how APIs for RSVP and ATM enable applications 
to control the QoS of their network connections. We have discussed how well 
the APIs reflect the needs of typical applications, and how they support the 
use of advanced operating system concepts. Finally, we propose directions for 
further development of QoS-aware APIs, namely unification of QoS descrip- 
tions with better abstraction from idiosyncrasies of the respective signaling 
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mechanisms, support for flows not involving the main processor, and improved 
means to cover the entire end-to-end data path with QoS guarantees. 
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Abstract 

Systemic meta-data is crucial for creating adaptive distributed applications. But 
managing systemic meta-data is extremely complex and currently is done either 
ad hoc or simply ignored. QoS savvy CORBA middleware is the appropriate place 
to manage systemic meta-data. In this position paper we outline the issues 
involved in this management. 
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1. Introduction 

Wide area and mobile environments exhibit a large variation in available resources 
and delivered quality of service (QoS). Distributed applications must therefore adapt 
to changes in their environment if they are to be effective under such extreme 
conditions. To adapt, applications must change their behavior at runtime based on 
the state of its environment. A basic requirement for such adaptivity is access to 
information about the underlying resources and application requirements. This 
systemic meta-data describes how applications use resources, their QoS 
requirements, the status of resources, and allocation policies. Without this 
information applications are rigid because they can only run in a limited and 
relatively predictable environment. 

Obtaining this systemic meta-data requires knowledge of how the system is 
implemented and deployed. Unfortunately, the traditional way in which distributed 
applications are developed is by using a black box abstraction which specifies what 
the component does — its functional interface — but hides how it was 
implemented. For example, CORBA’ s Interface Description Language (IDL) 
defines a functional interface for a remote object; e.g., a method to sort an array 
with a given argument signature. This black box approach works when a priori 
assumptions of the environmental conditions matches reality and when these 
conditions do not change. For a large class of environments the black box 
approach works fine, such as with programs contained in one process, and even in 
distributed programs working over local area networks (LANs). But, experience has 
shown that the black box approach is not adequate for all systems, especially 
distributed system running over a resource constrained network. 

* This research was partially funded by DARPA ITO under Contracts F30602-96- 
C-0315 (AQuA Project) and N66001-96-C-8529 (DIRM Project). 
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Abstractions of resources 
themselves hide their true 
distributed nature in order to 
provide an idealized in-core 
functional interface. For example, 
the socket interface provides a 
communications abstraction which 
allowed applications and networks 
to evolve independently (Fig. 1). 

This black box interface for 
application components and 
resources must be “opened up” to 
expose their internal structure 
because the functional interface is 
not enough to create adaptive distributed systems. Open Implementation research 
efforts focus on this problem for a single program [1]. In this approach, an 
additional systemic interface is used to map an application onto its environment in 
a workable fashion. 

In distributed systems many aspects of the internal development and fielding of an 
application are more explicit. They include the system properties, the roles of 
those involved (clients, objects, end users, programmers, etc.), commitment times 
(runtime, compile time, etc.), as well as the mechanisms to move this information 
around (available from a server, measured automatically, configuration parameter, 
etc.). The current state of development tools to support this is unwieldy and 
unintegrated and is a thus a great impediment to development and deployment of 
realistic applications over the wide area. 

2. Possible Solutions 

One solution is to try to provide in-core guarantees for distributed interactions; 
e.g., making a remote object invocation behave like a local procedure call. 
However, we believe this is impossible to provide, because it will be deficient in 
one or more of the following: high latency, prohibitive cost, or unworkable 
complexity. Pursuing this holy grail has driven much research in the last two 
decades, but it has become obvious that it is unachievable. 

A second solution which is much more achievable and features a much bigger 
payoff is to make the application more tolerant of the intrinsic limited guarantees 
(in the spirit of ISO QoS Compulsory levels of agreement [4; Sec. 7.3.2.4]) 
instead of trying to make the distributed infrastructure meet unobtainable system 
properties of a single host. This can be accomplished mainly by recognizing loose 
requirements; providing mechanisms with different, explicit resource tradeoffs; and 
by knowing when throwing more resources at the problem will help. 
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Figure 1: Distributed objects with QoS 
extensions is a powerful abstraction 
layer on which to build adaptive 
distributed applications. 
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Our Quality Objects (QuO) framework adopts this second approach by using open 
implementation techniques in the context of CORE A [2,3]. QuO provides a clean 
separation of functional and system issues. Elements of QuO are: contracts to 
define the interaction between clients and objects, system condition objects to 
observe the environment, and layers of delegates to mask variation. 

3. Structure of Systemic Meta-Data 

The basic life cycle of systemic meta-data is: first collecting, reducing, and 
summarizing it; disseminating it to interested parties; analyzing it; and acting upon 
it. However, providing this life cycle in a distributed system involves many facets, 
including: 

Mechanism: Systemic meta-data 

can travel between locations using 
several mechanisms supported by the 
underlying conununications 

infrastructure (Figure 2). 

Commitment epochs: As time 
progresses, a distributed system 
accumulates knowledge about its 
environment. E.g., at design time 
the different implementations are 
known, while at runtime the 
availability of a resource can be 
ascertained. 

Roles: Distributed systems are created, deployed, and used by multiple personnel, 
often in different organizations, with each responsible for a subset of the 
application. 

Location: Distributed systems ipso facto have multiple locations with high 

noise, limited bandwidth, and long latency between them. 

Granularity/Accuracy: Fundamental tradeoffs exist between obtaining accurate 
systemic meta-data and the resources and effort needed to obtain a level of accuracy. 

Kind: Multiple properties (ISO QoS characteristics [4]) such as availability, 
security, real-time, resource allocation need to be provided in an integrated fashion. 

Managing the interrelationship between all these facets is very complicated and is 
well beyond the capability of application programmers. We thus need QoS 
middleware which provides a framework to make these facets explicit and to help 
manage them. 
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Figure 2: Meta-data about system 
properties are transferred via 
disparate mechanisms 
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4. QuO SuppcNTt for Adaptive Applications 



QuO is a framework which makes these facets explicit with the following 
components (Fig. 3): 

System Condition Object 
Explicit objects which capture 
and maintain a specific piece of 
systemic meta-data. QuO 
supports a spectrum of system 
condition objects, from objects 
local to the client to remote 
CORBA objects. For example, 
one system condition object 
could measure the client’s 
method invocation rate while 
another may represent an 
interface to an RSVP session. 




Figure 3: QuO integrates 

meta-data through the use 



systemic 
of system 



condition 

delegates. 



objects, contracts, and 



Contracts: QuO contracts 

summarize system condition information and organizes them based on commitment 
epochs. For example, at negotiation time a contract may expect a client’s 
throughput to match network capacity. At runtime, however, these may diverge, 
and QuO provides hooks for recognizing this. 



Delegates: Delegates change the behavior of the object based on the region of 
the contract. For example, if the client invocation rate is greater than the capacity 
the delegate may block an invocation to implement traffic shaping. 



5. Areas for Future Research 

Supporting systemic meta-data falls under several areas of research. Networks need 
to support explicit mechanisms for moving and storing systemic meta-data. 
Application programmers need APIs for QoS at the client/object boundary rather 
than at the socket level. Finally, the semantics of the systemic meta-data itself 
needs to be codified so in the future we can automatically synthesize and reason 
about QoS. 

References 

[1] Kiczales, Gregor. Beyond the Black Box: Open Implementation, IEEE 
Software, January 1996. 

[2] Zinky, J., Bakken, D. and Schantz, R. Architectural support for quality of 
service for CORBA objects. Theory and Practice of Object Systems, Special 
Issue on the OMG and CORBA, 3(1), April, 1997. 

[3] QuO, Internet Publication,\JRL http : / / 

WWW. dist-sys terns .bbn.com/ tech/QuO 

[4] ISO/BEC 13236 - Quality of Service - Framework - DIS July 1996 








29 

Support Components for Quality of 
Service in Distributed Environments: 
Monitoring Service 

D. A. Reed and K. J. Turner 

Dept. Comp. Sci. And Math., Stirling University, Stirling, UK. 
E-mail: dar@ cs. stir. ac. uk, kjt@cs. stir. ac. uk 

Abstract 

One of the services required in a Quality of Service (QoS) oriented open distributed 
environment is monitoring. Instead of a bespoke monitoring system for each distributed 
application it is proposed that the optimum solution is a generic distributed service which is 
adapted to suit the application. The following approach can encompasses many of the QoS 
characteristics proposed in the draft ISO QoS Framework Standard. 

Keywords 
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1 INTRODUCTION 

Until recently Quality of Service (QoS) was not a vital issue in the design of open 
‘middleware’ systems but, since the introduction of multimedia services with time-critical 
characteristics and the need for synchronisation between data streams, this is changing. The 
Open Software Foundation (OSF) is investigating a number of QoS initiatives. Architecture 
Projects Management Ltd. (APM) is defining the Distributed Interactive Multimedia 
Architecture (DIMM A) (Otway, 1995), an extension of the real-time Advanced Network 
Systems Architecture (ANSA). 

This paper outlines a generic distributed QoS monitoring service which is tailored 
according to the distributed application. The methodology progresses naturally from formal 
temporal specification techniques, thereby aiding development and design of the distributed 
application. Also included is a brief description of QoS support services that a 
designer/programmer might expect of a QoS-oriented distributed environment. 



2 SERVICE COMPONENTS 

Five services are proposed for supporting QoS within QoS-oriented distributed 
environments: co-ordinating, monitoring, negotiating, networking and scheduling. The co- 
ordinating service provides the pivotal role, interfacing with the other services. The 
monitoring service deals with the operational concerns of a distributed application, warning 
of potential failures. The negotiating service deals with establishment concerns, particularly 
the QoS requirements between con^)onents of the distributed application, and between the 
same components and the distributed environment. The networking service deals 
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specifically with the establishment and management of communications resources. The 
scheduling service deals specifically with the establishment and management of local 
resources. Both the networking and scheduling service act as access control mechanisms. 



3 MONITORING SERVICE 

Monitoring is an essential service in a QoS-oriented distributed environment. There are 
three basic requirements of a monitoring service. The monitor must report QoS violations 
promptly, it should use few resources, and it should minimise interference when monitoring 
the application. As with many systems, the act of measuring within a system can perturb it. 
It is necessary to reduce this perturbation to a minimum. 

The proposed service is based on a ‘witness’ monitor. Each node in a distributed 
environment has a local monitor which collects information from components of distributed 
applications located at that node. Each distributed application has an associated global 
monitor which collates data collect from the local monitors associated with that application. 
A local monitor may collect information from many applications but a globd monitor 
collates data for only one distributed application. 

For the monitoring service to be generic there cannot be application-specific 
information conveyed to it from the distributed application. Events must therefore be 
generic in format. The conditions encapsulating the statement of allowed/disallowed 
behaviour are presented to the monitoring service in a general notation which may be 
applied to these generic events. Establishment of these conditions consists of the application 
first presenting a number of formal identifiers representing the events and a set of conditions 
expressed using these formal parameters to the monitoring service. This then issues 
currently available identifiers to the application. Each event is assigned to one identifier, 
although this event may occur more than once. The identifiers are referred to as colours. 

The concept of pair-wise interaction is the underlying model of this system. In a pair- 
wise interaction there is an action event and later in time a reaction event which is causally 
linked. This paper considers the basic case of 1:1 action/reaction pairs but the n:l case can 
be treated as n 1:1 cases. 

When an event occurs the application component must inform the local monitor 
immediately: signal s (colour, sequence, signature). The colour identifies the event, 
sequence identifies the occurrence of the event and the signature represents data at the 
event. The signature must be generated by the application to accurately reflect the data; the 
signature is used to check data integrity. The locd monitor time-stamps the signal to create 
an event tag ^signal, time-stamp). If a particular condition cannot be evaluated at the local 
monitor then event tags associated with that condition are collected into tag lists and 
periodically sent to the global monitor: tag list ^colour, (signatureo, time-stamp o), 
(signature 1 , time-stamp j), ..., (signature ft, time-stamp „)). 

The event and signal are considered atomic. Whether this requires critical sections of 
code will depend on the accuracy required of the time-stamp, frequency of the event and 
system overhead of critical sections. The local monitor does not acknowledge signals; the 
call is one way to reduce the impact on the components. Tag lists are only sent to the global 
monitor if necessary and the periodicity is determined by the required response time. 
Whether a condition can be evaluated locally or globally depends on the distribution of the 
application’s components. Co-location of some components could be beneficial. 

Conditions are composed of a number of Unctions and operators which may be 
applied to the event tags and to condition expressions. There are two basic functions which 
can be applied directly to an event tag: t(colour, sequence) returns the time-stamp and 
s(colour, sequence) returns the signature of the event tag with the matching colour and 
sequence number. The function c(colour) returns the number of times the event with the 
matching colour has occurred. Functions for comparing signatures and functions which 
count the number of times a condition has been true or false are also included. The basic 
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logical operators -i (not), a (and), v (or) are allowed to create complex conditions 
although it is not yet clear whether the language would benefit from V and 3 operators. 

This is the basis for a language which can be used to express QoS characteristics. It is 
not complete. In particular operators to flush the event counter and disable or enable 
conditions dependent on events or other conditions are of substantial interest. There is also 
the possibility of defining stopwatches within the local monitors to improve the range and 
response of condition statements. 

It is not anticipated that a distributed application would state its QoS conditions 
directly in these basic functions. Common QoS characteristics would be expressed using this 
language consisting of a set of macros which the application could instantiate. This set of 
macros would support an international standard such as the ISO QoS framework document 
(ISO, 1995). The next section illustrates how such macros can be constructed. 



4 ISO QOS 

The ISO QoS framework document outlines 54 QoS characteristics grouped into eight 
categories. Not all of these characteristics are suitable for this ‘tagging’ methodology. This 
section gives as examples the time delay characteristic and the non-specialised 
characteristics of capacity, accuracy and availability. 

The simplest characteristic is the ‘time delay’ characteristic. This is a building block of 
many other QoS characteristics. The example is interpreted as the time of the reaction event 
(col our 2 , n*** occurrence) minus the time of the action event (colourl, n^** occurrence) - 
possibly a latency. 

time delay s /(colour 2 ,n)- /(colour l,n) 



Many of the capacity characteristics can be measured by counting the number of action 
or reaction events. The example below is interpreted as the action event (colour) where m 
is a constant representing the value of one unit of capacity, for example a packet size. This 
condition therefore calculates the mean throughput. 

c(colour)xm 

capacity = -7 r — r 

/(colour,/i)- /(colour, 0 ) 

The accuracy characteristics require the application to distinguish between correct and 
incorrect reaction events. The following example is interpreted as the number of correct 
reaction events (colour 2 ) over the number of action events (colourl). 

c(colour 2 ) 

accuracy s ^ 

c(colourl) 

The availability characteristics require the application to indicate when a resource is 
available or unavailable. The example below reflects the definition of availability as Mean 
Time Between Failures (MTBF) divided by MTBF plus Mean Time To Repair (MTTR). 
The action event (colourl) is interpreted as ‘becomes available’ while the reaction event 
(col our 2 ) is interpreted as ‘becomes unavailable’. There are naturally other expressions 
which reflect availability. 
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availability ^ 



^r(colour2,/i)“ r(colourl,/i) 

2^0 

y.r(colourl,n + 1)~ /(colour 2,n)+ ^/(colour 2, n)- /(colour 1,«) 

n=0 n=0 



5 FUTURE WORK 

At present this monitoring methodology is tailored towards systems in which the monitored 
data is identical at the action/reaction events. The data is then used, in part, to establish the 
causality between the action/reaction events. This is particularly suited to monitoring 
network communications such as found in protocol stacks. Current work is implementing a 
version of this monitoring service between Stirling, Scotland and BT Labs, Suffolk UK. 
Principal problems include accessing a high resolution clock on the end-systems and 
establishing a global clock reference. These problems are non-trivial for a middleware 
solution. The lack of a high-resolution clock can be obviated by recasting the QoS 
conditions into statistical forms thereby reducing the need for such a clock, but only at the 
expense of the response time to QoS violation. Establishment of a global clock reference to 
a sufficient accuracy over an unreliable network is also cause for concern. 

Future work will extend this methodology to systems in which the data is transformed 
between events and to causally relate events between which there is no data transfer. This 
will naturally require the designer to embed a method of establishing the action/reaction 
pairs. It is anticipated that tools for automating this procedure will be developed, thus 
minimising the impact of this methodology on the designer and programmer. This work is 
also being evaluated with respect to the work at the University of Michigan, USA 
particularly ARMADA and the real-time fault tolerant monitoring systems (Jahanian, 1994). 
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Abstract 

The range of distributed applications has increased dramatically over recent years, 
fuelled in particular by the growth of the Internet and other Local Area and Wide Area 
Netwwks. Such applications tend to require user level knowledge of low-level tedinical 
parameto's and an appreciation of system heterogeneity issues, rather than simply stating 
what service they require. 

In this shmt pupei we describe a working system for ccHifiguring QoS for MBone 
conferencing applications. Here we use QoS profiles as a means of specifying 
resources and requirooients. 

Key words: QoS profiles, QoS resources, QoS requiranents 

1. INTRODUCTION 

This ps^ desoibes a system for configuring distributed multimedia services 
running in a heterogeneous environment, based upon the principle of using 
declarative QoS profiles [1]. There are two basic classes of QoS profile used in our 
approach: QoS required and QoS provided. We address the QoS of a media-type 
in terms of the end system capabilities rather than characteristics of the media- 
type sudi as frame play rate. In our practical work we have concentrated on end 
system resource capabilities since network aspects have been the subject of much 
attention in other studies. 

2. GENERAL PRINCIPLES 
2.1 System Description 

The QoS ConfiguratitMi System (Figure 1) provides a method fw configuring 
services whidi is largely genaic, requiring a minimal amount of service specific 
logic. It is a distributed application consisting of two parts: 

• The Configuration Engine, which is located on a single madiine. 

• A number of Terminal Resource Agents (TRA), one on each 
compute' that is partidpating in a sawice. 

Eadi end-system is fully involved in the configuration of a swvice by providing 
resource configuration inf(»mation to a service, satisfying the prindple of end-to- 
end systems design[2]. 

Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 
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Figure 1 QoS Configuration System Overview 



2.2 QoS Profiles 



We have used the concept of QoS profiles. We have four types of profile (Figure 
2): usCT, terminal, media, network, as derived from the diffoent viewpoints on a 
service. 



User 

Profile 



Terminal 

Profile 




Media-type 
Requirements 



Resources 



I Terminal 



Network 



Media-type 

Profile 




Network 

Profile 



Figure 2 Viewpoints on a Service 

These profiles rq)resent a declarative approadi to stating the QoS requirements of 
a SCTvice and the systan resources available to fulfil them. We have found that it 
is not possible to configure a service in a purely declarative manner, and that there 
must be some specific procedural logic to fully configure a service. 

In our system we have only implonented the media-type and terminal profiles, 
whidi are stwed in the Ccnifiguration Engine and the TRA respectively. Each 
TRA, representing eadi terminal involved in the service session, is asked to 
compare its profile with the media-type profile and say whetho: the terminal is 
capable of supporting that media-type. 

3. IMPLEMENTATION AND EXPERIENCES 

Our practical work is based upon a video/audio-confoendng syston. The 
conference organiser has the dioice of eithe' creating an audio/visual Mbone 
coiference using the vie and vat tools or making a CU-SeeMe call directly 
between themselves and another user [3,4,5]. In an ideal system this choice would 
be invisible to the use*; a multimedia conferencing system would select the best 
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application(s) for the task. However, this would require an additional negotiation 
layer between the Terminal Resource Agents and the Configuration Engine. 

3.1 Using the system 

Through the use of an almost obligatory WWW interface, the conference 
organise chooses the confa-ence participants and the desired media-types. The 
list of participants in the sa^ce and the sarice required are passed to the 
Configuration Engine. The Configuration Engine then maps the list of 
participants to the taminals they are currently using. The profiles of the media- 
types needed to run the SCTvice are retrieved from a database. The Configuration 
Engine then forwards the media-type profile(s) to each Taminal Resource Agent. 
This checks the media-type profile with its taminal profile and returns one of the 
following results: 

• The taminal is fully capable of siq>porting the media-type. 

• The terminal is NOT capable of suppating the media-type. 

• The taminal is not CURRENTLY capable of suppating the media- 
type but is potatially able to do so. 

The Configuration Engine then configures the service according to the results 
obtained. 

Applications are individually configured for eadi usa participating in the service, 
again with a WWW intaface being used to laundi helper applications. 

3.2 Alternative Styles of Working 

Thae are actually two methods in whidi the profiles can be passed: 

• Media-type profile passed to TRA (resources requested), simple result 
returned. 

• Simple request to TRA made, terminal profile raumed (resources 
offaed). 

In the case of video-confaendng with a large number of usas it is more scalable 
fa the media-type {urofiles to be sent to eadi Taminal Resoace Agait. Thus the 
comparisons can be conducted in parallel and the load is distributed ova a 
numba of machines. 

There is also a dioice as to how the TRA obtains the infamation fa the terminal 
profile. The two dioices are as follows: 

• Agait paiodically polls the systan seddng an update on resoaces. 

• Agent makes systan calls to discova resoaces when requested. 

In oa implanaitation we have chosai the latta coase of action, with the TRA 
obtaining its terminal profile through a system call to the Windows 95/Windows 
NT registry. 
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4. FUTURE EXTENSIONS 

We have already mentioned in section 2 above, that there are 4 separate profiles 
(terminal, media-type, netwOTk and user) but only the first two of these have been 
implemented. Further work will extend to cover the othCT profiles. 

The system could also be used to configure adaptive services. Take as an example 
a user moving firom an office environment to a mobile one. In the office they will 
have access to a high performance taminal and a high bandwidth connection. 
This changes to a lower paftsmance terminal opo'ating over a restricted 
bandwidth. The (^oS Configuration Syston will be used to det^mine which 
media-types can be run on each terminal. On the former the us^ might be able to 
partidpate in a video and audio conference. On the latt», the user would 
partidpate in the same omf^ence but with only an audio link. 

5. CONCLUSIONS 

The CJoS Configuration Syst^ offers the following benefits: 

• Abstraction ova* bet^ogeneous networks, applications and end systems. The 
Terminal Resource Agents all have the same int^ace regardless of the syst^ 
configuration. All applications are dealt with in the same way with only a 
small amount of service dependent logic. 

• Predictable session instantiation. 

• Simple user controls/interface. The user only has to state what they want set 
up, not how it is to be done. 

• Cost reduction to the provider of the sawice. 

New applications can be introduced by producing new media-type profiles; there 
is no need to change the Terminal Resource Agents. Also, the requirements of a 
media-type can be dianged without having to change eitha: the Terminal 
Resource Agents m the spedfic service logic. The interface of the tominal agent 
abstracts over the underlying terminal. 
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Abstract 

We propose an architecture where clients can make advance reservations 
through agents responsible for advance admission control. The agents allocate 
resources in the routers just before they are needed for packet forwarding. In 
this paper we show that network resources can be shared between immediate 
and advance reservations without being pre-partitioned. The admission con- 
trol schemes for immediate and advance reservations still operate with little 
interaction. 

Admission control decisions for immediate reservations use information 
about resources to be allocated for advance reservations in the near future. An 
important parameter in the admission control algorithm is the so called looka- 
head time, i.e., the point at which we actually start making resources avail- 
able for approaching advance reservations by rejecting immediate requests. 
In our model, preemption of immediate reservations is made in cases where 
the admission control cannot make resources available through rejection of 
immediate requests. The risk of preemption can be varied by changing the 
lookahead time when making immediate admission control. 

We explore, with simulations, the effects of providing advance reservations 
according to this model. The results show the cost in terms of resource uti- 
lization, rejection probability and preemption probability. 

Keywords 

QoS, advance reservations, resource sharing, agents, admission control 
1 INTRODUCTION 

Real-time applications such as audio and video conferencing may need re- 
source reservations in the network to perform well. However, many of the 
current resource reservation proposals allow only immediate reservations, i.e., 
reservations at the time the session begins, while real-time events often are 
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scheduled and advertized in advance. Clients making immediate reservations 
for scheduled events will have to judge the appropriate time for making reser- 
vation requests in order to be accepted in due time. When resources are scarce, 
clients may start making reservations earlier than needed, leading to sub- 
optimal scheduling of network resources. By offering reservations in advance, 
these problems can be alleviated. 

In (Schelen & Pink 1997), we present an architecture where admission con- 
trol for advance reservations is performed by agents on behalf of the routers 
in their routing domains. By participating in a link-state routing protocol, 
the agents know the topology and the static link capacities of their domains 
and can therefore select suitable routes and reserve resources over the links in 
advance. When the reserved resources are needed for packet forwarding, the 
reservation agents will allocate resources in the routers along the selected path 
and then periodically refresh those resource allocations through the duration 
of the reservation. 

Clients can make end-to-end reservations by contacting any agent. Requests 
involving several routing domains are handled by cooperation between the in- 
volved reservation agents. An advantage with an agent-based approach is that 
advance reservations can be provided without having to maintain reservation 
state in the routers through periods when the reservations have no effect on 
packet forwarding. Furthermore, the agent-driven approach does not require 
the reserving endpoints to be present until the session for which resources 
have been reserved is starting. Reservations can also be made for remote lo- 
cations, thereby supporting third party reservations and nomadic computing, 
i.e., reservations for places where the host will be moving in the future. 

In this paper we will show that network resources can be allocated through 
advance reservation agents. In particular we will show that pre-partitioning 
of resources is not necessary and that admission control for immediate and 
advance reservations still can be performed with little interaction. 

Admission control for both immediate and advance reservations could be 
performed by reservation agents provided that the admission decision is based 
on traffic specifications given by the clients and static link resources only. This 
is the case for admission control schemes offering some kind of performance 
bound (Firoiu, Kurose & Towsley 1996) (Shenker, Partridge & Guerin 1997), 
enforced by the packet scheduler (e.g., WFQ or EDF). However, there are 
other proposals where immediate admission is based on measurements of the 
used resources rather than the aggregate of the requested resources (Jamin, 
Danzig, Shenker & Zhang 1995) (Wroclawski 1996). We believe that the sig- 
naling overhead for having traffic measurement based admission control in 
agents may be prohibitive, and can be better served by having admission con- 
trol in the routers (where traffic measurement can be done directly). Also, 
to facilitate the integration of advance reservation support with current tech- 
nologies for immediate reservations, advance reservations should be managed 
separately from immediate reservations. 
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One way of separating the admission control for immediate and advance 
reservations would be to partition the resources so that one part is available 
for immediate reservations and another part for advance reservations How- 
ever, this would result in two logically separate networks with bad utilization 
due to the problem of partitioning resources according to current demand. 
Therefore, we have chosen to share resources between immediate and advance 
admission control. To allocate resources safely we have extended the imme- 
diate admission control to consider the near future concerning the resources 
that will be allocated for advance reservations. There are three major con- 
sequences of these results. First, the resources can be managed efficiently 
without suffering from badly chosen resource partitions. Second, the immedi- 
ate admission control scheme can be kept fast and simple by not having to 
consider advance reservations in the far future. Third, we have the architec- 
tural freedom of locating the admission control for immediate and advance 
reservations at separate places in the network without suffering undue com- 
munication overhead. Agents for advance reservations inform about resource 
allocations shortly before they are scheduled to happen. 

In our model, resources for advance reservations will be made available by 
rejecting immediate requests for a period before resources are to be allocated, 
or ultimately by preempting service for flows that were granted immediate 
access. We show, with simulations, the effects of advance reservations in terms 
of resource utilization, rejection probability and preemption probability. We 
have simulated admission control for a single link. 



2 SERVICE MODEL 

• Durations must be specified for advance reservations. A duration includes 
the start time and the finish time for the requested service. 

• Immediate reservations do not specify durations. Such requests are serviced 
immediately (if possible) and can be preempted later by flows that reserved 
in advance. 

• Preemption means that a flow loses its service quality; however, it will still 
be serviced at a best-effort level. 

• In order to manage resources safely there may be limits imposed on mini- 
mum and maximum bookahead times for advance reservations. 

• The admission control for advance reservations may support finding the 
earliest point for which a requested service can be granted. 

We have chosen not to include a service for immediate requests that are guar- 
anteed never to be preempted. One reason is that we aim at keeping the 
preemption probability low, so that the user need not worry about preemp- 
tion when asking for admission. Another more fundamental reason is that 
indefinite non-preemptible service would block resources indefinitely and no 
advance reservations of those resources could therefore be made. Furthermore, 
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resources that are reserved in advance for some time in the far future cannot 
be given to indefinite sessions in the meantime unless we have the option of 
preempting those sessions when resources are needed. To provide indefinite 
sessions, it is necessary to set aside resources for this service exclusively. In 
the Tenet suite (Ferrari, Gupta & Ventre 1995), resources are partitioned to 
support advance reservations and non-preemptible immediate sessions simul- 
taneously. However, there will be some fragmentation due to it being hard 
to maintain the partitioning such that the the demand for the two different 
services are met at each instant. We could support indefinite sessions by using 
such a partition in our architecture as well. However, in this paper, we will 
investigate whether or not we can avoid some problems with resource frag- 
mentation by sharing resources between immediate and advance reservations 
and instead allow for statistically rare cases of preemption. 



3 RESOURCE SHARING BETWEEN IMMEDIATE AND 
ADVANCE RESERVATIONS 

When immediate reservations and advance reservations share resources and 
the duration of each immediate reservation is unknown, there is a risk of 
over-allocation that can be made less likely with preemption. The probabil- 
ity of preemption can be controlled by either monitoring immediate requests 
when admitting advance reservations, or vice versa, by monitoring advance 
reservations when admitting immediate requests. 

When advance reservation requests are made far in advance, the informa- 
tion obtained from monitoring present traffic will not be useful for advance 
admission control (Degermark, Kohler, Pink k Schelen 1995). Most of the 
active fiows would have finished at the crucial time anyway. It is only when 
advance reservations are requested with very short notice that it would be 
valuable to know about present traffic. Since advance reservations are pro- 
vided to meet the demand for scheduled sessions primarily, we believe that 
most reservations will be requested on a notice much longer than the average 
session length. We may even impose this in the reservation agents by having 
a minimum bookahead time for advance reservations. 

On the contrary, by monitoring advance reservations for the near future 
when admitting immediate requests, we can to some extent control the risk 
of preemption. If there are insufficient resources available in the near future, 
the request could be rejected instead of serviced. It is up to the provider to 
decide whether rejection or preemption is preferable in these cases. Reject- 
ing immediate requests because the resources are reserved in the near future 
means that the overall utilization will go down to make room for the advance 
reservations. We denote the pre-allocation time, i.e., the time for starting to 
set aside resources for advance reservations as the lookahead time into the 
advance reservation state. Setting the lookahead time is an internal issue to 
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the admission control scheme. We denote the time from making an advance 
reservation until the resources are to be available as the bookahead time. The 
bookahead time is set by the clients asking for admission and varies from 
request to request, possibly within some limits imposed by admission control. 



4 SIMULATIONS 

The objective of our simulations is to explore the effects of allowing reser- 
vations in advance. The performance measures are link utilization, rejection 
probability, and preemption probability. We vary the fraction of the total link 
resources used for advance reservations and the lookahead time into advance 
reservation state at admission control for immediate requests. Admission de- 
cisions are based on reservation specifications (e.g., traffic specifications) pro- 
vided by the clients. For simplicity we start with peak rate resource allocation, 
using the requested bandwidth as the only parameter. This study is for ad- 
mission control over a single link only. 

4.1 Simulation parameters 

• The duration of immediate requests, i.e., the call hold time, is exponentially 
distributed with a mean of 300 time units. 

• The duration of advance requests, is also exponentially distributed with a 
mean of 300 time units. 

• The bookahead time for advance requests, i.e., how far in advance the 
advance requests are made, is exponentially distributed with a mean of 20 
000 time units, where the tail is cut at 60 000 units (i.e., there is a maximum 
bookahead time). 

• The total link capacity is 45 000 resource units. 

• The resources asked for in each request are uniformly distributed in [1..3000] 
resource units. 

• The inter-arrival time of admission requests is exponentially distributed 
with a mean of 11.76 time units. This number was selected to obtain a rea- 
sonable rejection probability, where around 6% of the requests are rejected. 
The average offered load is 85% of total capacity. 

• When preemption is performed, the immediate request with the largest 
requested capacity is picked as a victim (which would encourage making 
requests in advance when large capacity is needed). 



The simulations are run many times for each parameter set, with different 
seeds for the random variables. The 90% confidential intervals are computed 
and presented as error bars in the plots (although the confidence is often so 
tight that the error bars appear as dots). 
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4.2 Advance reservation requests 

We vary the fraction of the admission requests that are made in advance 
between zero and one. The upper bound on resources available for advance 
reservations equals the total link capacity, resulting in advance reservations 
being seldomly rejected when a small fraction of the requests are made in 
advance (Figure 1). 




Figure 1 Rejection probability for advance requests 




Figure 2 Average duration for accepted advance requests 

Figure 2 shows that the average duration of the granted requests goes down 
as there is a higher fraction of advance reservations. When resources are scarce, 
advance reservations will result in some fragmentation in time, and there is a 
greater chance that requests for short durations are accepted. This effect does 
not occur for immediate requests since admission is made without considering 
durations (in fact, durations are unknown). 

A similar effect can be observed concerning the average bandwidth given to 
the granted requests. If the offered load is increased, the average bandwidth 
for granted requests will go down as the rejection probability goes up. How- 
ever, for advance reservations the rejection probability also depends on the 
bookahead time. Therefore, users requesting large bandwidth have a stronger 
motive for reserving well in advance to avoid rejection. 

4.3 Total link utilization 

Figure 3 shows that the total link utilization goes down as the fraction of 
advance reservations increases. There are two reasons for this. First, we must 
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start allocating resources ahead of the starting point of the durations for ad- 
vance reservations in order to avoid having to preempt immediate requests. 
The result depends on how far in advance we start setting-aside resources, 
i.e., how far we look ahead into advance reservation state when deciding if 
there is capacity available for an immediate reservation. Second, fragmen- 
tation in time is introduced when advance reservations are allowed. There is 
little chance that other advance requests ask for the small fragments that may 
be available between already granted advance reservations. Consequently, a 
decrease in utilization can be observed as the rate of advance reservations is 
increased, even though there is no pre-allocation, i.e., the lookahead is zero 
and preemption is the only means for making resources available. 




Figure 3 Total link utilization 

This may sound like bad news for providing advance reservations, but in 
fact similar drops in total utilization would be observed as soon as there are 
scheduled events introduced in the network, even though users were to make 
only immediate reservations. Users would still be likely to allocate resources 
before events begin to make sure that they have resources allocated in time. 
The only difference is that the control is with the clients instead of with the 
network. The degree of over-allocation in time would be a consequence of 
social behavior in an environment with scarce resources. In some situations 
we can expect that effective utilization drops in an uncontrolled way. 

Measurement-based immediate admission control could alleviate the prob- 
lems of low utilization, but since we cannot get any useful measurements until 
the traffic starts, we must choose between staying with the traffic specification 
given by the client or gradually losing the resource allocation as the measure- 
ment procedure finds that there is no traffic. When there are scheduled events, 
advance reservations are likely to improve the service and the total utilization 
by ensuring that resources are allocated at an appropriate time. 

4.4 Rejection and preemption probability 

Figure 4 shows that the rejection probability for immediate reservations in- 
creases as the fraction of advance reservations is increased. However, the 
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change in rejection probability for immediate requests is primarily an effect of 
picking the victims among a smaller set of immediate requests as the rate of 
advance reservations increases. If we instead monitor the total rejection prob- 
ability (Figure 5) over both immediate and advance requests, we get much 
lower risk of rejection (note that the scales are different). Perhaps this is a 
better reflection of overall user satisfaction. 




Figure 4 Rejection probability for immediate requests 




Figure 5 Total rejection probability (for immediate and advance requests) 




Figure 6 Preemption probability for immediate requests 

We can see that the rejection probability is about the same when we have 
only immediate requests as it is when we have only advance requests, i.e., 
around 6 %. The decrease in total utilization (Figure 3) is explained by the 
fact that the average duration for accepted requests goes down (due to frag- 
mentation in time) with increasing demand for advance reservations (Figure 
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Figure 7 Total preemption probability (for immediate and advance requests) 



Figure 6 shows that the preemption probability increases as the fraction 
of advance reservations is increased. Again, part of the explanation is that 
all preemption victims are picked within the immediate requests and as the 
fraction of immediate requests goes down we get a higher risk of preemption 
for this service class. In Figure 7, we show the preemption probability over 
the total number of served reservations. 

It is clear that increasing the lookahead time makes admission control more 
conservative, resulting in lower preemption probability at the cost of lower 
utilization and higher rejection probability. By decreasing the lookahead time, 
we allow the system to be more overbooked resulting in higher preemption 
probability. The fact that the system is allowed to be overbooked explains 
why the total rejection probability (Figure 5) goes down when we use zero 
lookahead and there is a suitable fraction of advance reservations. 

4.5 Lookahead time 

Given a desirable target for preemption probability, the lookahead time can be 
conservatively computed by considering the bandwidth that must be allocated 
for each advance reservation and the amount of bandwidth that is returned per 
time unit by immediate reservations ending. However, at reasonable load it is 
likely that there are some unallocated resources that should be considered as 
well. In our simulations, between 75% and 79% of the resources are allocated 
on average, which explains why it is possible to allocate resources for advance 
reservations with a total preemption probability below 5%, even when using 
zero lookahead. 

In previous examples we kept the lookahead times constant as the fraction 
of advance reservations was increased. We have also tried to use exponentially 
distributed lookahead times, but we found a strict performance degradation 
compared with constant lookahead time. If there are problems in meeting 
the requirements for high utilization and low preemption probability, we may 
be forced to have a limit imposed on resources available for reservations in 
advance. As an example, we now fix the advance request rate to 40% of the 
total number of requests (i.e., the average is bounded and there is no firm 
bound) and we plot the performance measures as functions of the lookahead 
time 
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Figures 8, 9, and 10, show the effects. It is clear that the preemption prob- 
ability falls steeply as the lookahead is increased. In most systems, like cel- 
lular phone systems, preemption is considered bad and should be avoided. In 
a packet switched network, preemption is not as bad since the packets are 
still served best-eflFort. We believe, however, that the relative weight of hav- 
ing low preemption is still high. Provided that we have the average duration 
for resource reservations (assuming exponentially distributed session lengths), 
the fraction of advance reservations, and the individual weights (set by the 
provider) for utilization, blocking and preemption, we can find a suitable 
lookahead time. 




Figure 8 Rejection probability for immediate requests, at 40% advance request 
ratio 
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Figure 9 Preemption probability for immediate requests, at 40% advance request 
ratio 




Figure 10 Utilization for immediate requests, at 40% advance request ratio 
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With a 40 % advance reservation request rate, we can, for example, use 
a lookahead of 50 time units, resulting in 77.6% of the resources being al- 
located under a 1.1% immediate request preemption probability (i.e., 0.44% 
total preemption probability). By using a lookahead of 100 time units, we get 
a utilization of 76.9% at a preemption probability of 0.35% for immediate 
requests. This is to be compared with 79% of the resources being allocated 
when there are no advance reservations. The offered load is in both cases 85% 
of the total capacity and the total rejection probability is around 7%. 

If there were reservation agents without supporting lookahead in the imme- 
diate admission control algorithm, the results would be the same as having 
zero lookahead (the network must support preemption and non-blocking re- 
source allocation that can be used by the advance reservation agent). In that 
case we have 5% preemption probability for immediate requests when 40% of 
the admission requests are made in advance. 



5 CONCLUSION 

Reservations for scheduled events run the danger of over-allocating resources 
independently of whether advance reservations are provided. By encouraging 
advance reservations for scheduled events, resources can be more accurately 
allocated over time compared to what would be the case if clients themselves 
had to decide when to allocate resources through immediate reservations, 
especially, when resources are scarce. 

Our simulations show the effects of providing advance reservations. We as- 
sume allocating resources at some point for each reservation and the utilization 
is measured in terms of how much we can allocate. We do not consider drops 
in the link utilization due to reserved resources not being used. 

In our model, resources are shared between advance and immediate admis- 
sion control, i.e., there is no pre-partitioning of resources. The most important 
parameter in the admission control algorithm is the so called lookahead time, 
i.e., the point at which we actually start making the resources in the routers 
available for approaching advance reservations. The paper shows how a suit- 
able lookahead time can be found through simulations. 

The effects of advance reservations can be expressed in terms of rejection 
probability, preemption probability, and total link utilization. In the simu- 
lations presented we can allocate 79% of the link resources when there are 
no advance reservations and around 77% of the resources when 40% of the 
admission requests are made in advance, and there is a 0.4% preemption prob- 
ability for immediate requests. The offered load is in both cases 85% of the 
total capacity and the total rejection probability is around 7%. 
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Abstract 

In a video-on-demand (VoD) system the user can select and play movies according 
to his/her own quality of service (QoS) requirements; upon receipt of the user 
request, a typical VoD system checks whether there are enough available resources 
to deliver the requested movie to the user’s host. If the response is yes, the movie 
presentation can start; otherwise, a rejection is sent back to the user; this means that 
the response is based only on the system’s load at the time the request is made and 
assumes that the service duration (movie length) is infinite. In this paper we pro- 
pose a scalable VoD (SVoD) system which decouples the starting time of the serv- 
ice from the time the service request is made and requires that the duration of the 
requested service must be specified. In response to a user request, S VoD determines 
the QoS with which the movie can be presented at the time the service request is 
made, and at certain later times carefully chosen. As an example, if the requested 
QoS cannot be supported at the time the service request is made, SVoD allows to 
compute the earliest time, when the user can play the movie with the desired QoS; 
this time can also be determined in a way to use multicast communication to 
deliver the same movie to several users. The scalability achieved by SVoD is quan- 
tified and compared with that of typical VoD; the performance quantification, per- 
formed through the use of simulations, shows that SVoD achieves high resource 
utilization and decreases notably the blocking probability of user requests. 

1 INTRODUCTION 

A video-on-demand (VoD) system allows users to select and play movies accord- 
ing to his/her own quality of Service (QoS) requirements (Brubeck and Rowe 
1996; Buddhikot et al. 1994; Genunel et al. 1995; Lougher 1993; Rangan 1993). 
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Typically, when a VoD system receives a user request to play a movie with a certain 
QoS, it checks whether there are available resources to open one or more streams to 
deliver the movie. If the response is yes, the movie presentation can start; other- 
wise, a rejection is sent back to the user. This implies that a second attempt of the 
user cannot take advantage of information obtained through the first request to 
change, if possible, the requirements to fit the current system load; a user who tries 
several times to play the movie during a short period of time, e.g. 5 minutes, with- 
out success will be certainly discouraged and will likely look for another provider. 
Furthermore, a user can be rejected at the time he/she made his/her request while 
system resources become available just a short time, e.g. 1 minute, after the user 
made his/her request. This can bring unpleasantness to users and loss of revenues 
to service providers. This is due to the fact that existing VoD systems provide the 
user with the service that can be supported at the time the service request is made, 
and assume that the service is requested for indefinite duration. We believe that 
such systems do not fit the needs for future multimedia (MM) service providers and 
users. 

In this paper we present a scalable video-on-demand (SVoD) system which 
decouples the starting time of the service from the time the request (to play a 
movie) is made and requires that the duration of the requested movie must be spec- 
ified. SVoD is based on the ideas behind the negotiation approach with future reser- 
vation (NAFUR) which is described in (Hafid et al. 1997). In response to a service 
request, NAFUR allows to compute the presently QoS available and at certain 
future times. Certain of these future times may be times which correspond to the 
starting times of the same service requested by other users for whom the resources 
are already reserved. The user has the choice to start: (a) immediately with the 
presently QoS available; or (b) in a later time with the requested QoS and likely 
with less money to pay since only a part of the required resources should be 
reserved (the other part is already reserved for other users); 

The scalability of SVoD is achieved through the use of future reservations of 
the system’s resources and the use of multicast communications to deliver the same 
movie to several users. 

The paper is organized as follows. Section 2 presents an overview of NAFUR. 
Section 3 describes SVoD architecture. Section 4 presents the simulation model 
used to quantify the performance of SVoD and VoD. The simulation results are pre- 
sented in Section 5. Finally, Section 6 concludes the paper. 

2 AN OVERVIEW OF NAFUR 

NAFUR is a new QoS negotiation approach that decouples the starting time of the 
service from the time the service request is made and requires that the duration of 
the requested service must be specified. NAFUR allows to compute the QoS that 
can be supported for the time the service request is made, and at certain later times 
carefully chosen. As an example, if the requested QoS cannot be supported for the 
time the service request is made, the proposed approach allows to compute the ear- 
liest time, when the user can start the service with the desired QoS. NAFUR is 
designed to be used by any distributed system requiring negotiation with the user 
(human or not), e.g. video-on-demand and teleconferencing systems. 
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For sake of simplicity and clarity we model a distributed system as a single 
module and a QoS manager (Figure 1) which represents the access point to the 
module. The ability of the QoS manager to process a service request is directly 
related to the admission criteria which the QoS manager uses to decide whether a 
new request is accepted or not. This criteria is that the sum of previously assigned 
resources plus the resources required by the new request should not exceed the 
resources of the system. In the case of acceptance, the QoS manager reserves the 
required resources. When the QoS manager receives a request to terminate the 
service it simply de-allocates the reserved resources. When a renegotiation request 
is received, the QoS manager may decrease the amount of the reserved resources if 
the new QoS is less restrictive than the QoS currently provided, otherwise, it 
checks the admission criteria with the new QoS constrained by the current load of 
the system. In this section, the terms “system” or “QoS manager” will be used 
interchangeably. 

More specifically, the following operations are provided by the QoS manager to 
the users (Figure 1): 

(1) Serviceinq (in req : Request; resPeriod : Time; out pro : Proposals); 

(2) ServiceRes (in req : Request; out s : Status); 

The operation Serviceinq makes an inquiry about the availability of a particular 
service characterized by a request req . This parameter is a tuple of three elements 
req=<Q , starttime , length>, where g is a set of QoS parameters characterizing 
the quality of the requested service, starttime is the desired starting time for the 
service, and length is the length of the time for which the service is requested; the 
period for which the service is requested is therefore the time interval [start time , 
starttime + length ]. The result pro is a set of proposals where each proposal indi- 
cates the QoS available for a period of length at some future times. Formally, a 
proposal is defined as a tuple <time, QoS> where QoS represents the QoS that can 
be supported by the system over the interval [time, time + length] . 



users 




Figure 1. System model 

The parameter resPeriod (argument of Serviceinq) indicates for how long the 
service reservations (made to support pro ) should be kept (on a temporary basis) 
until a subsequent invocation of the ServiceRes operation will make an effective 
reservation for a particular proposal. The operation ServiceRes is used to effec- 
tively make a service reservation. Typically, it will be called after the execution of a 
Serviceinq operation, and its req parameter will correspond to one of the proposals 
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contained in pro . The status parameter, s , indicates the success or failure of the 
operation. 

To support the operation Serviceinq, we assume that the QoS manager has 
enough knowledge about the available QoS, presently and in the future; this infor- 
mation is called available service projection {asp ). Formally asp consists of a list 
of tuples [{time QoS {time. , QoS where QoS^ corresponds to the QoS 

that can be supported by the component at time time. . 

For each tuple, <t. , QoS.>, of the available service projection (ASP), the QoS 
manager checks whether QoS. holds for a period of time, equal or higher than the 
length, length , of the requested service. If the response is yes, then <t. , QoS.> 
may be considered as a potential proposal; otherwise, the QoS manager will con- 
sider the tuples which have their time values smaller than t. + length and higher 

than t. , to compute the minimum QoS which might hold for a period equal to 

length , starting from t. . The QoS manager produces a list of proposals; however, 

not all the proposals are useful to be presented to the user. A kind of filtering is sup- 
ported by the QoS manager to compute only the representative (“useful”) proposals 
(Hafidetal. 1997). 

NAFUR provides suitable mechanisms to encourage the system resource shar- 
ing using multicast communication. Upon receipt of a service request, the QoS 
manager computes the presently QoS available and at certain future times. Certain 
of these future times may be times which correspond to the starting times of the 
same service requested by other users for whom the resources are already reserved. 
When the QoS manager returns the proposals, if the user selects a proposal for 
which the required resources (or part) are already reserved (for another user), only 
a part (or none) of the required resources are reserved. 

A more detailed description of NAFUR for an arbitrary system topology and 
the underlying mathematical theory of NAFUR can be found in (Hafid et al. 1997). 

3 SYSTEM ARCHITECTURE 

Figure 4 presents the architecture of our SVoD; each video server (respectively host 
machine) is extended with a agent, we call server agent (respectively user agent); 
these agents implement a basic version of NAFUR as described below. The archi- 
tecture shown in Figure 4 is essentially independent from the technologies and soft- 
ware in use; this does not mean that the agents have the same implementation code. 
Rather, an agent offers an interface which provides a certain number of standard 
operations, but the implementation of these operations depends on the component, 
e.g. its technology and the software it supports. 

SVoD can be easily extended with new video servers without code modification 
of the existing agents; one has only to implement the agents to be installed in the 
new servers. It is obviously imperative that an agent communicates with the server 
where it is hosted; access primitives allow agents to use abstraction as long as the 
components agree on the basic language of access. However, a server is free to 
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implement an access primitive in whatever way it sees fit. In this paper we focus on 
the operation of a single video server. 




Figure 4. Architecture of SVoD 
2.2. User agent 

The user agent consists mainly of three components: user interface, QoS manager, 
and SVoD client controller (Figure 5). The user interface is mainly divided into two 
parts. The first part offers a means to search and select a movie from a database; 
this means that a video server is selected to deliver the movie. The second part 
allows to specify the desired presentation quality and cost constraints; it also allows 
users to renegotiate the desired QoS during the movie presentation. 




Figure 5. User Agent Architecture 



When the user selects a movie and specify his/her requirements, the user inter- 
face sends a message to the QoS manager. The latter starts by checking whether the 
client machine characteristics, such as the screen size and the screen color, support 
the requested QoS. If the client machine does not support the QoS requested by the 
user, the QoS manager sends a rejection (with an offer) to the user via the user 
interface; the user has three choices: abandon the request, accept the offer, or initi- 
ate a renegotiation. Otherwise, the QoS manager sends a message (which contains 
the user requirements) to the SVoD client controller. Then, the latter builds a mes- 
sage, we call simply request, and sends it to the corresponding server agent; it 
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enters a loop waiting (at a specific host port) for a response and initiates a timer. 

If a time-out is reached before the reception of a response, a rejection is sent to 
the user via the user interface; otherwise, the proposals contained in the received 
message (which corresponds to the response of the server agent) are presented to 
the user, via the user interface by “NAFUR processing unit”. If the latter accepts 
one the proposals, then SVoD client controller invokes (immediately or in later 
time for delayed presentation) the appropriate video player to display the movie; 
this is done via a “message interpreter” which maps the message received via the 
host port to a primitive to start the corresponding video player. Otherwise, a rejec- 
tion message is sent to the server agent. 

2.2 Sever agent 

A video server in our system can be any kind of video server which has the func- 
tionality (1) to provide delayed service provision (future reservation of resources) 
when there are not enough resources to support the delivery of the requested 
movie; and/or (2) to serve several users with a single video stream. Ideally, this 
functionality should be inherent to the server which means that the server integrates 
this functionality as part of its software; this means that the server implements a 
subset of the suite of algorithms provided by NAFUR. However, any existing video 
server (research server, e.g., the continuous media file server described in (Neufeld 
et al. 1996), or commercial server, e.g. VDOLive On-Demand (VDOnet 1996)) can 
be used if it installs a server agent (see Figure 4). 

At any time, a server agent is waiting at a specific server port for requests from 
user agents. Each time it receives such a request, it stores information (of interest) 
related to this request (Figure 6), it updates the information it has, and it forwards 
the request to the server. Then, the server checks its capacity to deliver the 
requested movie with the desired QoS and sends the response to the server agent; 
we assume that the server starts the delivery of the movie only after a confirmation. 



information_List 



movie 

identifier 


Starting 

time 


movie 

length 


quality of 
service 


“Casablanca” 


20:00 


1,5 hour 


TV quality 


1 

1 


1 

1 


1 

1 


1 

1 

1 



Figure 6. Information maintained by the server agent 

If the server’s response is a rejection, the server agent checks (in its 
information_List) whether the delivery of the requested movie is scheduled for 
another user; if the response is no, the server agent determines the time when there 
will be enough resources to support the request (when one or more current or lately 
scheduled presentations end). In both cases a message is sent to the user agent; the 
message contains proposals for delayed presentation of the requested movie. Then, 
the server agent enters a state waiting for a confirmation message from the user 
agent. 

If the server’s response is an acceptance, then the server agent checks the possi- 
bility (in the future) of using multicast communication to deliver the requested 
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movie; if the response is no, the server’s agent sends an acceptance message to the 
user agent; otherwise, a message that contains two proposals (actual and delayed 
presentation using multicast) is sent to the user agent. In both cases, the server 
agent enters a state waiting for a confirmation 

The network in our system should support the multicast facility; otherwise, 
SVoD will make use only of future reservation of resources facility. Obviously, if 
there are not enough available network resources, the delivery of the movie cannot 
be performed; we assume that the network has (at any time) available resources to 
deliver the movie from the server to the user. However, some protocols can be used 
to check the availability of network resources; for example, RSVP (Zhang et al. 
1993) or the Tenet Protocol suite (Ferrari and Verma 1990) can be used for network 
resources reservation for inunediate movie presentation; for delayed presentations, 
the network should be capable of reserving its resources in advance. 

4 MODEL DESCRIPTION 

To evaluate the performance of our system we performed a number of simulation 
experiments. More specifically, we run three classes of simulations: 

(1) Simulations without future resources reservation facility nor multicast com- 
munication 

(2) Simulations with future resources reservation facility 

(3) Simulations with future resources reservation facility and multicast commu- 
nication. 

The service request to play a movie is defined by <id, g , starttime , length> 
(see Section 2). 

4.1 Simulation parameters 

The simulations are parameterized by the following: 

- User request type: this process is used to model the class of QoS the clients will 
ask for. We have assumed that we have three classes 1,2, and 3 that correspond to 
gj , g 2 , and respectively. Each class is characterized by the amount resources 

to reserve in order to support this class.The users will request the more popular 
class, 1 , more often. The probability that a user requests the class i is given by p. . 

The following service request type pattern is assumed: pj = 0.8, = 0.1 , and 

P3 = 0.1 . 

- Number of users making requests (NU): the number of users making requests over 
a given period of time; we consider a population of 400-1900 users. 

- User Request pattern in time: indicates the distribution of user requests over a 
day; this distribution presents a peak during the evening when most users likely ask 
to play a movie. A normal distribution, characterized by its mean (X = 3.5 ) and its 
variance (a = 60 ), is selected to model the evolution of this parameter. 

‘Length of the service requested (LSR): this process is used to model the genera- 
tion of the lengths, length , associated with the service requests. We assume that the 
length associated to a service request is uniformly (randomly) distributed between 
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60 min and 90 min. 

- Maximum delay parameter (MDP): indicates the maximum difference (between 
the time the request is made and the starting time of a delayed presentation) which 
is acceptable by the user; a value of 0 for this parameter means that the user does 
not accept any delayed presentation of the requested movie. 

- Movie selection pattern: indicates how users select one of the available movies 
(e.g. 50 different movies). We assume that most popular movies are the most 
requested; the following is a default selection pattern: 80% of users selects the five 
most popular movies (i = 1, ..., 5 ); 15% of users selects the 25 less popular mov- 
ies (i = 6, ..., 25 ); 5% selects the 20 least popular movies (i = 26, ..., 50); 

4.2 Performance measures 

The main metric we adopted for evaluation and comparison was the rejection 
probability: rejection probability^ (number of rejections)/(number of service 
requests); a rejection corresponds to a rejection initiated by the system or a rejec- 
tion initiated by the user who does not accept a delayed presentation (in this case 
MDP is smaller than the difference between the time of the request and the time of 
the future proposal returned by NAFUR). 

Simulation Hypothesis 

We assume that (1) the system is characterized by its maximum capacity R; and (2) 
j2| , 02 » 2s supported if 0.0050% of R, 0.0070% of R, and 0.0030% of 
R is available, respectively. 

5 SIMULATION RESULTS 

We study the impact of 4 parameters on the performance of our SVoD. These 
parameters are: the time the requests are made, the number of users in the system 
(NU), maximum delay parameter (MDP), the amount of the system resources. 

All results are compared to a typical VoD system. For figures 8 through 12, 
curves denoted by U correspond to user requests issued; curves denoted by S corre- 
spond to SVoD without multicast; curves denoted by SM correspond to SVoD with 
multicast; and curves denoted by V correspond to typical VoD. 

5.1 System behavior over time 

In Figures 8 the X-axis indicates the time in minutes (e.g. if 0 represents 17:00, 
then the peak of user requests is around 20:00); the Y-axis indicates the number of 
requests made and accepted in the last 20 minutes. The figure shows the user 
requests made over time, and the number of requests accepted by the system when 
using a typical VoD, SVoD without multicast facility, and SVoD with multicast 
facility. For this experiment we assume that the number of users is 1000, and users 
do not accept presentations which are delayed more than 1 hour (60 minutes). 

Figure 7 shows that the number of accepted user requests is much higher with 
SVoD than VoD; particularly, this holds during the peak of user request distribution 
(between 120 and 280). 
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Figure 7. User requests issued and user requests accepted 

The number of requests made and the number of streams started in the last 20 
minutes are shown in Figure 8. A large number of requests rejected using VoD are 
scheduled for future presentations using SVoD. SVoD is much better at handling a 
large number of requests made over relatively short period of time. 

It is obvious that SVoD with multicast facility performs much better than SVoD 
without such a facility; the use of multicast conununication is the best way to serve 
more users in a video-on-demand system than the approach of one-to-one connec- 
tions between the users and the system. This is due to the sharing of (server and 
network) resources between a number of users asking for the same movie 




Figure 8. User requests issued and users served 



5.2 Maximum delay parameter 

In Figure 9, the X-axis indicates the maximum delay parameter; the Y-axis indi- 
cates rejection probability multiplied by 100. The figure shows that the blocking 
probability decreases when the value of the maximum delay parameter (MDP) 
increases; this holds when using SVoD since VoD is not affected by varying MPD. 
Hie impact of MPD is most significant when using SVoD with multicast facility. 
One may argue that it is not realistic to assume that users will accept delayed pres- 
entations with a delay of 30 or 60 minutes; nevertheless, we believe that users will 
prefer to get a feedback from the system about the status of their request. NAFUR 
provides the feedback on the time the requested presentation can start and the qual- 
ity of the presentation. We think that a good number of users will be attracted by 
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money discounts for delayed presentations. Last and not least, users may book in 
advance in order to obtain a reservation. 




Figure 9. Blocking probability Vs maximum delay parameter 
5.3 Number of users 

In Figure 10, the X-axis indicates the number of users making requests; the Y-axis 
indicates rejection probability multiplied by 100. The figure shows the impact of 
increasing the number of users requests. Blocking probability increases when the 
number of users increases for VoD and SVoD. The best gain using SVoD is 
achieved when the number of users is around 800-900; the blocking probability 
with SVoD is around 0-5 and the blocking probability with VoD is around 30-35%. 
When the number of users is more than 1000, the gain achieved by SVoD (without 
multicast facility) slightly decreases to stabilize; while the blocking probability 
with SVoD (with multicast facility) increases slowly than the blocking probability 
of others. 




Figure 10. Blocking probability Vs number of users 
5.4 Amount of system resources 

In Figure 11, the X-axis indicates the capacity of the system in terms of % of R 
(e.g. R, 1.5*R, 2*R); the Y-axis indicates rejection probability multiplied by 1(X). 
The impact of increasing the maximum amount of the system resources is shown in 
Figure 11. For this experiment the number of user requests is 1500, and the value of 
the maximum delay parameter is 60 minutes. 

The blocking probability of SVoD and VoD decreases when the amount of the 
system resources increases. However, the blocking probability decreases faster 
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than the blocking probability of VoD. Thus, in this experiment if we want to have 
SVoD with 0% blocking probability we have to increase its maximum amount of 
resources (R) by 0.65 *R. 

If the designer’s of SVoD knows about the average number of potential users 
with the distribution of their requests over time, he/she can build a system with an 
average 0 as a blocking probability. 




Figure 11. Blocking probability Vs amount of system resources 
6 CONCLUSION 

Upon receipt of a user request to play a movie, a typical video-on-demand (VoD) 
system does start the movie presentation if there are enough available resources; 
otherwise, a reject message is sent to the user. Since no more information is sent 
back to the user, the latter may try several times to get the movie without success 
(e.g., the server is loaded at maximum for a certain period of time). 

In this paper we have proposed a scalable video-on-demand system (SVoD) 
which uses a future reservation of resources and multicast communications. When 
SVoD receives a user request (with some QoS requirements) and has not enough 
resources to support it, it does compute the QoS that can be supported immediately 
and the exact time in the future when the user can play the requested movie. SVoD 
schedules future presentations in a way to make extensive use of multicast commu- 
nications. That is, if a presentation of a certain movie is scheduled in some time in 
the future, say T, and one or more users ask to play the same movie at < 7, 

SVoD will schedule the presentations for these users (after their confirmation) to 
start by T ; SVoD will use multicast communication to deliver this movie at T and 
thus will make use of less much resources than using one-to-one connection with 
the users. 

A performance analysis of SVoD shows that we can service more users than 
typical SVoD systems. This allows us to create a system that can service a large 
number of users for a reasonable cost. We can state that SVoD is more efficient and 
flexible than typical VoD systems. Furthermore, the ideas behind SVoD can be eas- 
ily used to enhance the functionality of existing commercial and research VoD sys- 
tems. 
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Abstract 

In this paper, we present a method of QoS mapping between user’s preference 
on video quality and a required bandwidth to transport the video across the 
network. We first investigate the mapping method from QoS parameters to 
the required bandwidth on the network. For this purpose, we assume that the 
underlying network supports some bandwidth allocation mechanism, such as 
DBR service class in ATM, RSVP, IPv6 and so on. Then, for given QoS param- 
eters in terms of spatial, SNR, and timely resolutions, the required bandwidth 
to support the MPEG-2 video transmission is determined by analyzing the 
traced MPEG-2 streams. We next consider the mapping method between QoS 
parameters and the user’s perceived video quality, which is quantified by MOS 
(Mean Opinion Score) evduation. Based on the above results, we discuss a 
systematic method to estimate the required bandwidth to guarantee user’s 
preference on video quality. 

Keywords 

QoS architecture, MPEG-2, bandwidth allocation, perceived quality 
1 INTRODUCTION 

A distributed multimedia system requires the QoS (Quality of Service) guar- 
antee to achieve its effective presentation (Campbell et al. 1996). QoS guar- 
antee is performed in each of entities within the multimedia communication 
system. As an example, in the Video on Demand (VoD) application, the video 
server is responsible for providing a multi-client real-time access to stored 
video libraries, continuous data emission, and an interaction mechanism with 
clients. The client provides users with the continuous and high quality video 
presentation and a means of QoS control to reflect user’s preference on the 
perceived video quality. Further, the underlying transport network requires 
some mechanism for the distributed multimedia application to guarantee QoS 
requested by the users. 

The distributed multimedia system should take account of user’s preference. 
Some users may prefer slower, but detailed video appearance while other users 
may choose more coarse but faster video presentation. Those preferences on 
the video quality have to be mapped onto QoS parameters that each entity can 
understand (Figure 1), and all of them cooperate with each other to provide 
the required QoS on perceived video quality. 

Video data coded by any coding ^gorithm (e.g. MPEG (ISO/IEC DIS 

Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 

© 1997 IFIP. Published by Chapman & Hall 




292 



Part Eight QoS-based Transport Protocols 



User 




User's Prefemce QoS Parameters 




fast, clear 
slow, coarse 




Spatial resolution \ 
SNR resolution I 
Timely resolution ' 



Bandwidth 

Negotiation 



(Mbps) 



Network 




Figure 1 Prom users’ preference to bandwidth 



11172 1991)) are transferred over the transport network. The network is re- 
quired to provide some bandwidth control mechanism to guarantee the re- 
quired QoS for each connection. One example is the ATM (Asynchronous 
Transfer Mode) network, which is now a well-known transport network for 
an effective multimedia data transfer (The ATM Forum 1995). In ATM, ser- 
vice classes have been standardized to support various QoS guarantees in 
two standardization bodies, ITU-T and the ATM Forum (ITU-T 1992 revised 
in 1995, Garrett 1996). Among them, either SBR (Statistical Bit Rate) or 
DBR (Deterministic Bit Rate) is suitable for video data transfer with QoS 
guarantee since those two service classes have a capability to guarantee the 
transfer delay, delay jitter and cell loss ratio. Between two, the SBR ser- 
vice class seems to be more preferable because an effective bandwidth usage 
can be expected by means of statistical multiplexing, and QoS guarantees 
are provided. However, the SBR service class can only perform QoS guar- 
antees statistically, and requires complicated UPC/C AC mechanisms (Krunz 
et al. 1995, Newman 1994). On the other hand, in the DBR service class, 
bandwidth allocation is performed based on PCR (Peak Cell Rate) and the 
deterministic QoS guarantee is provided as far as the cell emission rate is kept 
under the allocated bandwidth (Newman 1994). Other transport mechanisms 
such as RSVP (Braden et al. 1996) and IPv6 (Deering et al. 1995) also pro- 
vide the bandwidth allocation mechanism to provide the deterministic QoS 
guarantees. 

In those bandwidth allocation based networks, connection setup is per- 
formed by allocating the enough bandwidth to that connection. It means that 
the required bandwidth must be known or estimated a priori at the connection 
setup time. However, the bandwidth prediction for coded video traffic is known 
to be very hard since the traffic characteristics must depend on the coding 
algorithm and contents of the video sequence. It is especially true when the 
coding algorithm allows to adaptively encode the video according to the user’s 
preference. If the coded video is stored in the server’s storage, a completely 
accurate amount of the required bandwidth would be decided. However, under 
the heterogeneous environment, various kinds of QoS requirements would be 
required by clients and it becomes ineffective to prepare many video streams 
of various resolutions. Thus, the video server must adapt the coding method 
according to the user’s preference. As a result, the characteristics of generated 
video traffic also vary. 

Some researches have already been devoted to traffic prediction issues (see, 
e.g., (Singh et al. 1995, Heyman et al. 1996, Wu et al. 1995) and references 
therein), but their results are not applicable to the case discussed in the 
above. Especially when user’s preference are taken into account, the prediction 
algorithms presented in those papers are not useful any longer, because they 
consider the behavior of video traffic coded with some specific parameter sets. 
For example, in (Yeadon et al. 1996), they investigated the effectiveness of 
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several filtering control methods on the throughput of MPEG coded video 
streams. However, their approach does not provide the way to estimate the 
required bandwidth when users are allowed to set arbitrary values for QoS 
parameters. 

Prom the network side, the network resource is limited. Thus, even when the 
traffic prediction can be performed accurately, the requested bandwidth may 
not be admitted by the network due to the lack of network resources. How- 
ever, the reduced bandwidth may be accepted by the network if the quality 
degradation is allowed by the user. A problem is that we do not have any de- 
vice to decide QoS parameters for a given bandwidth. Further, when the user 
dynamically changes QoS parameters during the connection, the allocated 
bandwidth should be re-computed and re-negotiated through the signaling 
protocol such as Q.2963 (ITU-T Draft Standard Q.2963 1995) or ABT (ATM 
Block Transfer) (Guillemin et al 1996). When the enough bandwidth is not 
available and re-negotiation fails, it is possible that the user reduces the band- 
width, and then try the bandwidth reservation again using those protocols. 
A remaining problem is how to decide the reduced bandwidth while keeping 
little degradation in perceived video quality. 

Prom above observations, one of most important issues in the distributed 
multimedia architecture is to investigate the relationship between QoS param- 
eters and the required bandwidth (Figure 1), which is one of main subjects of 
this paper. As QoS parameters, we will consider spatial resolution (the number 
of pixels), SNR resolution (the quantization degree) and timely resolution (the 
number of frames per second) of MPEG-2. Then, we examine the effect of the 
scalable control mechanism (i.e., QoS parameter setting) of MPEG-2 coded 
video stream on the perceived video quality through MOS (Mean Opinion 
Value) evaluation. The obtained relationship is useful to decide the appro- 
priate bandwidth at the call setup time and at the bandwidth re-negotiation 
time. Or, when the bandwidth is limited, the user can set the QoS parameters 
such that the perceived video quality is kept as high as possible. Of course, 
such a relationship is applicable to existing multimedia systems such as the 
one in (Chang et al 1996). 

This paper is organized as follows. We first briefly summarize the QoS 
parameters on the perceived video quality in Section 2. In Section 3, we inves- 
tigate the quantitative relationship between QoS parameters and the required 
bandwidth. Further we investigate the influence of QoS parameter set on the 
perceived video quality in terms of MOS values in Section 4. By combining 
those results, mapping from user’s requested video quality to the required 
bandwidth can be established. It can be utilized when the user establishes the 
connection of video transfer as described in the previous section. Or, inverse 
mapping from the available bandwidth to user’s perceived quality can also 
be built, which is useful for the flexible bandwidth re-negotiation mechanism 
between the user and the network. We will discuss this aspect in Section 5. 

2 QOS PARAMETERS FOR MOTION VIDEO 

In this paper, we assume that user’s preference can be related to QoS param- 
eters in terms of spatial resolution scalability, SNR (Signal to Noise Ratio) 
resolution scalability, and timely resolution scalability of MPEG-2 videos, 
which will be briefly summarized in this section. 
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Table 1 Video characteristics (640x480 pixels, 30 fps, Q=10) 



sequence 


Scenery 


Starwars 


Live 


Comedy 


max (Mbps) 


14.373 


10.715 


9.085 


11.192 


mean (Mbps) 


4.063 


4.919 


2.428 


4.889 


burstiness 


3.538 


2.178 


3.742 


2.289 



The spatial resolution of perceived video is described by the number of 
pixels in each frame. As the preferred spatial resolution, users may select 
640x480 pixels, 320x240 pixels or 160x120 pixels. When the user receives the 
video streams of 640x480 pixels large, the user can enjoy the detailed and 
high quality video contents. When the received video is 320x240 pixels large, 
on the other hand, the user would suffer from the coarse and rough quality 
of video when it is enlarged on the TV monitor, or the smaller and degraded 
quality of video on the computer monitor. However, the required network 
bandwidth to transfer 320x240 video is certainly smaller than 640x480 video. 
In this paper, we will assume that the TV monitor is used, and henceforth, 
the frame size of 320x240 video is enlarged by four times when its perceived 
quality is compared with that of 640x480 video in Section 4. 

The SNR resolution scalability is realized by adjusting the degree of quan- 
tization during the video coding process. The quantizer scale can be adjusted 
without MPEG-2 codec with full capability since only de-quantization and 
quantization are required in this case. The quantization in the MPEG-2 cod- 
ing algorithm is performed by applying specific quantizer scale against each 
block of 16x16 pixels large. When a larger quantizer scale is applied, the qual- 
ity of decoded block becomes poorer, which leads to degraded SNR values. 
However, the coded block size can become smaller, which has a positive effect 
from a viewpoint of effective resource usage within the network. 

The timely resolution of received video is related to the number of frames 
per second (fps). The frame rate of coded MPEG-2 video stream can be regu- 
lated by means of a frame dropping technique. MPEG-2 video stream consists 
of three types of frames, I (Intra coded), P (Predictive coded) and B (Bi- 
directionally coded) frames. One of the video sequence we use in this paper 
has a cyclic sequence of IBBPBB, which is called GoP (Group of Pictures). 
The frame rate can be reduced by dropping some frames. Since the least in- 
fiuential frames are B frames, we can drop B frames first. The resulting GoP 
structure then becomes I BP B and the frame rate is reduced by two thirds, 
i.e., from 30 fps to 20 fps. By displaying the preceded frame repeatedly, the 
empty frame time should be filled. As we will show in the below, it can be 
expected that the video quality is not degraded by dropping B frames. How- 
ever, the required bandwidth cannot be reduced by doing so since the size of 
B frames are much smaller than other I or P frames. We will discuss this issue 
in more detail in Section 3. 

In Sections 3 and 4, we will discuss QoS parameters of MPEG-2 video de- 
scribed in the above in relation to the required bandwidth and the user’s 
perceived video quality, respectively. Before proceeding to those sections, we 
summarize the statistics of MPEG-2 coded video streams used in our inves- 
tigation. We employ four different video streams which are coded from laser 
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Figure 2 Time dependent behavior Figure 3 Peak rate of coded video 
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disks. Those are Scenery, Starwars, Live and Comedy. Their characteristics 
are summarized in Table 1 and the rate transition of Scenery is depicted in 
Figure 2. In the table, we show the traffic rate in terms of Mbps and burstiness 
in terms of ’’peak to average ratio” for the case where the spatial resolution 
is set to be 640x480 pixels, the frame rate is 30 frames per second and the 
quantizer scale is 10. For other QoS parameters, we will use 640x480 pixels, 
320x240 pixels and 160x120 pixels for the video size. The maximum frame 
rate is 30 frames per second, and GoP structure is IBBPBB or IPPPPP. The 
quantizer scale will be chosen from a range of 1 (highest SNR) to 112 (low- 
est SNR). As shown in the tables and figures, the video characteristics are 
widely varied. Our main objective is then to find some common properties in 
those videos so that the result can be applied to handle MPEG-2 videos in 
multimedia systems with QoS guarantees. 



3 QOS PARAMETERS AND REQUIRED BANDWIDTH 

There are two alternatives in allocating the bandwidth to VBR traffic such 
as MPEG-2 coded video data. One is to allocate the bandwidth equal to the 
actual peak rate of the video stream. By this bandwidth allocation policy, 
all the data can be delivered to the destination without buffering delay and 
data loss. It is thus preferable for interactive applications where end-to-end 
transfer delay should be kept as small as possible. In this case, we employ the 
GoP structure of IPPPPP since coding of B frames requires the buffering of 
preceding and following frames for further effective data compression. When 
the application can tolerate large buffering delay at the source and/or within 
the network, on the other hand, the required bandwidth can be decreased by 
rate smoothing, which will be discussed later in this section. 

In Figure 3, the peak rate of the coded video streams are presented de- 
pendent on the quantizer scale for different spatial resolutions (pixels). From 
the figure, we can observe that the absolute values of peak rate are differ- 
ent, but the same tendency is obtained independent on video content, spatial 
resolution and frame rate; as the quantizer scale becomes larger, the peak 
rate decreases. Further, the larger quantizer scale does not contribute to the 
decrease of the peak rate when it is beyond 35. To see the above-mentioned 
relationship more clearly, the peak rate is normalized by the peak rate in 
the case where the quantizer scale is 10. The result is shown in Figure 4. In 
obtaining this figure, the spatial resolution and the frame rate are set to be 
640x480 pixels and 30 fps, respectively. From Figure 4, we can estimate the 
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peak rate of the video sequence for a given quantizer scale if we can know 
the peak rate of some quantizer scale. For example, if the peak rate for the 
quantizer scale of 10 is 10 Mbps, the peak rate for the quantizer scale of 20 
must be about 7 Mbps. This relationship also holds even when the spatial 
resolution is changed as shown in Figure 5, where the effect of the spatial 
resolution on the relation between the quantizer scale and the peak rate is 
shown by using the video stream Scenery, 

We next investigate the effect of the spatial resolution (the number of pixels 
in each frame) on the peak rate. Figure 6 plots (1) the ratio of the peak rate of 
640x480 pixels video to that of 320x240 pixels video, and (2) the ratio of the 
peak rate of 160x120 pixels video to that of 320x240 pixels video. Those lines 
appear in the upper and lower region of the figure. The horizontal axis shows 
the quantizer scale. As shown in figure, the relationship is kept unchanged 
independent on the quantizer scale and the video content. The peak rate of 
640x480 pixels video is about 3.1 times larger than that of 320x240 pixels 
video. This result is due to the MPEG-2 coding algorithm. When the number 
of pixels of each frame becomes four times larger, the number of blocks to 
compress also becomes four times larger. Since the header information must 
be attached with the coded frame data, however, the amount of coded data 
is only 3.1 times larger than that of the smaller video. 

When the timely resolution is degraded by dropping one or more frames of 
GoP, the resulting peak rate decrease is inversely proportional to the number 
of dropped frames in the peak rate based bandwidth allocation. It is because 
by dropping B frames, the empty time slots are generated, and henceforth, the 
transmission rate of I and P frames can be reduced as shown in Figure 7. Of 
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course, as a result of frame dropping, the extra buffering delay is introduced 
and the perceived video quality in timely resolution must decrease. 

We have found that there is a common tendency in the relationship between 
QoS parameters and the required bandwidth independently of the video con- 
tent. First, the same relationship is held between the quantizer scale and the 
required bandwidth independently of the other QoS parameters. Second, there 
is another relationship between the spatial resolution and the required band- 
width. Third, the required bandwidth is inversely proportional to the number 
of dropped frames when the bandwidth is allocated based on the peak rate of 
video traffic. From these facts, we can estimate the required bandwidth from 
the QoS parameters as follows. 

From Figures 4 and 5, we can express the relationship between the required 
bandwidth BWq and the quantizer scale Q as: 

Q 707 4 ^14 

BWq ^ (0.151 + ^ X BWio (1) 

where BWio is the required bandwidth for the case where the quantizer scale 
being 10. The constants in Eq.(l) are chosen to fit the curve in Figure 4 (we 
visedfit function of Mathematica), From Figure 6, we observed that the re- 
quired bandwidth for the video sequence becomes 3.1 times larger when the 
number of pixels is four times larger than the smaller video sequence. Fur- 
thermore, the required bandwidth is inversely proportional to the frame rate 
when the peak rate based bandwidth allocation is performed. Using Eq.(l), 
the required bandwidth {BW{R, Q, F) [bps]) to guarantee the preferred video 
quality can be estimated as functions of spatial resolution {R [pixels]), the 
SNR resolution (Q) and the timely resolution (F [fps]) as follows: 

BW(R,Q,F) “ (0.151 + ^ - ^)^BWiase (2) 

where BW^ase is the required bandwidth for the case of (JR, Q, F) = (640 x 
480, 10, 30). For example, inScenery, since BWtase is 14.373 Mbps for {R, Q, F) 
= (640 X 480, 10,30), we can depict Figure 9 from Eq. (2). As shown in the 
figure, we can accurately estimate the required bandwidth for any set of QoS 
parameters from Eq. (2). Although not shown in the figure, Eq.(2) is dso 
applicable to the other MPEG-2 video streams, Starwars, Live and Comedy. 



4 QOS PARAMETERS AND PERCEIVED VIDEO QUALITY 

In the previous section, we have shown the relationship between QoS param- 
eters and the required bandwidth. In this section, the relationship between 
QoS parameters and the user’s preference on perceived video quality is inves- 
tigated. By this way, we can know how the user’s perceived video quality can 
be mapped into the bandwidth, and vice versa. 

The perceived video quality is quantified through user’s subjective evalu- 
ation by using MOS (Mean Opinion Score). Each testee gives a score from 
1 (Poor) to 5 (Excellent) to the video sequence in experiments. Those scores 
are then gathered, and the MOS value is determined as 

* ^ . number of persons who give score i 

MOS = > i X ^ 2 (3) 

“ number of testees 

*=i 
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Figure 8 Effect of Frame dropping 




Quantizer scale 



Figure 10 MOS evaluation (Scenery) 




Quantizer scale 

Figure 12 Effect of QoS control on 
peak rate 




Quantizer scale Q 



Figure 9 Comparison between esti- 
mated rate and actual rate (Scenery) 




Quantizer scale 



Figure 11 MOS evaluation (Comedy) 




Figure 13 Effect of QoS control on 
MOS 



Five testees participated in the experiments. In experiments, we assume that 
the received video is shown on the TV monitor and every frames are enlarged 
to 640x480 pixels large. 

In Figures 10 and 11, we show the results of MOS evaluation on Scenery 
and Comedy for various sets of the spatial resolution (640x480, 320x240 and 
160x120 pixels), the SNR resolution (quantizer scale from 1 to 43) and the 
timely resolution (10 and 30 fps). As shown in the figures, reduction of the spa- 
tial resolution results in significant degradation of the perceived video quality. 
The 160x120 video sequences achieve the lowest subjective quality and qual- 
ity variation is indistinguishable. When the timely resolution is reduced from 
30 to 10 fpSj the MOS value decreases since frame dropping decreases the 
smoothness of video presentation. The effect of reduction of timely resolution 
in Comedy (Figure 11) is a little bit larger than in Scenery (Figure 10). This 
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result comes from the fact that Scenery consists of scenes with slow-moving 
while Comedy is made up of highly active scenes. 

By taking into account the required bandwidth for given QoS parameters 
(Section 3), we obtain the following observation. Reducing the SNR resolution 
is a most effective way to decrease the required bandwidth while keeping the 
perceived video quality as high as possible. For example, the peak rate can 
be reduced to about a half when the quantizer scale is changed from 10 to 
35 as shown in Figure 3. On the other hand, degradation in the MOS value 
can be kept to be no more than one in this case. However, an increase of the 
quantizer scale to more than 40 has no effect in saving the bandwidth. Further, 
reduction of the quantizer scale to less than 10 has no effect in increasing the 
perceived video quality. Henceforth, we should decrease the timely resolution 
next if the buffering delay induced by frame dropping is allowed. If further 
reduction of bandwidth is necessary, the spatial resolution should be reduced. 

As an example of this QoS control mechanism, we consider the case of 
Scenery, We assume that the quantizer scale ranges from 10 to 40, the timely 
resolution is either 10 or 30 ^s and the spatial resolution is 640x480, 320x240 
or 160x120 pixels. Suppose that the user first requests the highest QoS, i.e., 
(i?,Q,F) is determined as (640x480,10,30). Then, the required bandwidth 
becomes 14.373 Mbps. When the required bandwidth is not available in the 
network, the SNR resolution is first decreased to reduce the bandwidth. At this 
time, other resolutions are kept to be unchanged. It results in the reduction of 
bandwidth from 14.373 Mbps to 5.414 Mbps as shown in Figure 12 by the top- 
most arrow. However, the perceived video quality is also decreased as shown 
in Figure 13 by the topmost arrow. When the quantizer scale becomes 40, the 
timely resolution is degraded from 30 to 10 fps. When decreasing the timely 
resolution, we increase the SNR resolution again to maintain the perceived 
video quality as high as possible as shown in Figures 12 and 13. If further de- 
crease of bandwidth is necessary, the SNR resolution is degraded again, and 
then the spatial resolution is degraded. With this QoS control mechanism, 
the required bandwidth can be decreased while keeping the perceived video 
quality as high as possible. 

5 BANDWIDTH ALLOCATION MECHANISMS WITH QOS 
GUARANTEES 

In what follows, we will explain how our results presented in Sections 3 and 
4 can be applied to the distributed multimedia communication architecture 
for providing users’ preference (QoS) guarantees. An abstract model of the 
communication architecture is illustrated in Figure 14. A similar architecture 
can be found in (Chang et al. 1996) and we believe that our results obtained 
in the current paper are also applicable to such an architecture. In the figure, 
the video data flow is depicted by the solid line. For the control messages, 
another connection is required as depicted by the dashed line in the figure 

When the user establishes the multimedia connection, he/she first sets up 
the connection to the server with control messages. Together with the control 
message, he/she describes his/her preference on the perceived video quality 
by means of QoS control panel as shown at the top righthand corner in Fig- 
ure 14. In the figure, user’s preference is directly associated with a set of QoS 
parameters; the desirable spatial, SNR and timely resolution (R,Q,F). How- 
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Figure 14 Distributed multimedia communication architecture 



ever, more abstract representation is also applicable. For example, the user 
may want to select the degree of smoothness of the motion video. In that case, 
the results obtained in Section 4 can be used for more user-friendly interface. 

In either way, QoS parameters decided by the user are sent to the server, 
and it decides whether the user’s preference is acceptable or not. If the sender 
can provide the user with the video data of user’s specified QoS parameters, 
then it determines the required amount of the bandwidth from the set of QoS 
parameters, which has been discussed in Section 3. Note that if the bandwidth 
reservation is performed in the receiver oriented fashion as in RSVP, a map- 
ping from QoS parameters to the amount of bandwidth should be performed 
at the client. Eq. (2) is applicable only if we can estimate the peak rate of 
the video with a single set of QoS parameters. This is an easy task when the 
video is coded and stored at the server. 

However, Video encoding may be performed in a real-time fashion. In that 
case, we do not have any information about the characteristics of the video 
sequence. Then, at the connection setup time, some reasonable value must be 
used as BWhase in Eq. (2). This value should be large enough to guarantee 
the required preference, but the larger amount of bandwidth results in the 
larger failure probability in bandwidth reservation. When BWhaae is inappro- 
priately decided and the inadequate bandwidth is allocated, the bandwidth 
re-negotiation protocol (e.g. ABT) can be utilized. And BWhase can be dy- 
namically regulated to fit the actual coded video trafiic as described later. 

If the server cannot provide the user with the video of the required prefer- 
ence, or if the required bandwidth is not available within the network, then 
the QoS parameters must be decided again. To reduce the required amount 
of bandwidth, one or more QoS parameters should be degraded in the way 
that is described in Section 4. The user is informed with this QoS adaptation 
on the QoS control panel through the QoS query component. 

After the bandwidth allocation is successfully performed, the compressed 
video stream is transferred from the server to the client over the allocated 
bandwidth. The received video stream is de-compressed by the MPEG-2 de- 
coder and displayed on the monitor. The resolution of the displayed video is 
monitored by the QoS query component. By applying the information about 
the receiving video resolution and the amount of allocated bandwidth to Eq. 2, 
BWhase is dynamically adapted to fit the actual characteristics of receiving 
video data. When the monitored resolution does not satisfy the user’s prefer- 
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ence because of the inappropriately allocated bandwidth, or the user dynami- 
cally changes the preference on the perceived video quality, the allocated band- 
width is re-negotiated by means of the appropriate signaling protocols such 
as Q.2963 or ABT. In the case of RSVP where dynamic QoS re-negotiation 
is allowed, the bandwidth re-negotiation is performed through the reservation 
messages (RESV) (Braden et al. 1996). 

6 CONCLUSION 

In this paper, we have presented the relations between QoS parameters and 
the required bandwidth presented in Section 3 and from QoS parameters 
and user’s perceived quality in Secticm 4. From these results, we have ob- 
tained the QoS mapping method between user’s preference on video quality 
and a required bandwidth to transport the video across the network. We use 
MPEG-2 as a video coding system in this paper. However, we think our QoS 
mapping method is also applicable to the other coding systems which employ 
DCT algorithm, such as H.261 or Motion JPEG. It can be applied to design 
the distributed multimedia communication architecture with perceived video 
quality supports. It is demonstrated by illustrating the example. Our result 
can also be useful for the heterogeneous environment in the case where the 
multiple client requests different QoS. It can be implemented by utilizing the 
QoS aggregation technique, but the description is omitted due to space limit. 
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Abstract 

A framework for studying the end-to-end QOS mapping between the various 
levels of the transport protocol stack is presented. A platform for evaluating 
end-to-end QOS that supports concurrent network, transport and application 
level measurements is described, QOS measurements for various video clips 
indicate that the loss bound obtained under the assumption of uniformly 
distributed cell losses within a video frame is too conservative. 

Keywords 

Quality of Service, QOS Mapping, End-to-End QOS, Multimedia Networks 



1 INTRODUCTION 

The task of guaranteeing end-to-end QOS requires the understanding of the 
various levels of specification of QOS of the protocol stack. For example, 
switch vendors are concerned only with per-hop, per-class cell-level QOS while 
multimedia applications are concerned with end-to-end, per connection frame- 
level QOS. It is the end-to-end QOS, rather than the per-hop QOS, that is 
perceived and important to the users. Furthermore, network operators use the 
latter for guaranteeing QOS to their users and need to translate user QOS into 
network QOS. Each of these QOS specifications deal with different statistical 
quantities that have to be mapped into each other. 

The focus of this paper is on the mapping of loss characteristics between 
the application level and the network level. In particular, we consider frames 
(video frames and audio packets) at the application level, and ATM cells at the 
network level. That is, we are investigating the relationship between frame loss 
and cell loss. Application-to-network QOS mapping is needed to reserve the 
appropriate amount of network resources at connection establishment time. 
Furthermore, good mapping rules are essential in order to avoid reserving too 
much (or too little) resources. Finally, we are concerned with end-to-end QOS 
mapping. We assume that it is the responsibility of the routing to determined 
the per-hop QOS given the end-to-end network QOS. 

Building QoS into Distributed Systems A. Campbell & K. Nahrstedt (Eds.) 

© 1997 IFIP. Published by Chapman & Hall 
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This paper is organized as follows: Section 2 presents the QOS mapping 
rule widely used in the literature. To validate this mapping rule, we present 
in Section 3 a measurement platform for evaluating the end-to-end QOS. The 
platform supports concurrent network, transport and application level mea- 
surements of QOS. In Section 4 measurement results are presented. Finally, 
we review some related work in Section 5. 



2 END-TO-END QOS MAPPING 

The process of translating QOS specifications between different levels of the 
protocol stack is called QOS mapping. User-to-application mapping is needed 
to ease the process of selecting QOS at the human-machine interface. It is 
a mapping from a set of user preferences to a quantitative description of 
the service desired. Application-to-network mapping is needed to reserve the 
appropriate network resources at connection establishment time. It is assumed 
that it is the responsibility of the QOS routing system to find a route providing 
the required end-to-end cell level QOS. Thus, it is the responsibility of the 
routing to aggregate the per-hop QOS on a route and ensure that it satisfies 
the end-to-end QOS requirements. Finally, application- to- transport mapping 
is needed for monitoring and adapting to the rapid network fluctuations of 
QOS. In this paper, we address only on the application-to-network parameter 
mapping and focus mainly on loss. 

Let us define what we mean by end-to-end QOS specification: for any level 
in the protocol stack, the QOS is specified (and measured) from the moment 
a level L protocol data unit (PDU) crosses the boundary from level L to L-1 
at the source endpoint to the moment it crosses the boundary from level L-1 
to L at its destination endpoint. In particular, the end-to-end network QOS 
will be given in terms of cell level statistics between the network adapter of 
the source endpoint to the network adapter of the destination endpoint and 
the application level QOS will be given in terms of frames from the moment 
a frame is grabed and sent to the moment it is received and played back. 

Three descriptors are used for traffic characterization: the maximum pro- 
tocol data unit size (e.g., maximum video frame size, audio packet size and 
ATM cell size), average PDU size and the maximum PDU rate (e.g., video 
frame rate, audio packet rate, peak cell rate); when combined, the descriptors 
give the peak rate, the average rate and the burstiness of the media stream. 
The parameters used in the QOS profile are the maximum PDU delay, the 
maximum PDU loss rate and the average PDU gap loss*. At the destination, 
these parameters need to be measured over a time interval called the measure- 
meni era. The era can be finite or infinite; i.e., a fixed measurement window 
or the duration of a connection since its beginning, to- In the latter case, at 
any time t, the era is dynamically set to t — to- The era is also part of the 



The PDU gap loss is the number of consecutively lost PDUs. 
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QOS profile. When measurements are obtained over a (short) fixed era, we 
will sometimes refer to them as instantaneous measurements. 

The QOS mapping is generally done in two steps: a mapping between the 
services and traffic descriptors and a rescaling of the parameters of the QOS 
profile. Here, we look only at the parameter mapping. The application sends 
complete frames and receives complete, error free, frames. The transport uses 
AAL5 framing, and thus, a frame is lost if any of the following occurs: one 
or more cells are missing (due to buffer overflow, clipping or pure loss), a cell 
misinsertion or AAL5 CRC failure due to bit error. 

Let a, n denote the application and network, respectively. To write param- 
eter mapping rules, the following symbols are needed: 



R{1): 


PDU max rate 


(# pdu/sec), 


S{1): 


PDU max size 


(bytes/pdu), 


Ail): 


PDU ave. size 


(bytes/pdu), 


L(l): 


PDU loss rate 


(# pdu/sec), 


DU): 


PDU (end-to-end) delay 


(sec), 


G{1): 


PDU ave. gap loss 


(# pdu). 


eta{l): 


measurement era 


(sec). 



where / is either a or n. Finally, the peak rate at level / by PR{1) = S{1) • R{1) 
(bytes/sec) and the average rate AR{1) = A{1) • R{1) (bytes/sec). 

Intuitively, if the cell loss is small (say less than lO”"^), the frames not too 
small (say larger than 2k bytes (or 40 cells)) and the losses are uniformly 
distributed within a frame, then the following relation should hold 

L{n) = L{a) • A{n)/A{a), (1) 

For example, if a frame loss of 10”^ is desired, with average frame size of 
2400 bytes then the cell loss should be about 10”^ • 48/2400 or 2 • 10“^. 

In order to empirically evaluate the loss mapping rule prescribed by Equa- 
tion 1, we have been performing experimental loss measurements concurrently 
at the application, transport and network level. 



3 A QOS MONITORING PLATFORM 

We have implemented a QOS measurement system for each level in the pro- 
tocol stack. To allow for application level measurements, frames are times- 
tamped when grabbed and just before being played back. For the transport 
level measurements, TPDU are timestamped when sent by the application 
and when available for delivery to the application. Finally, for network QOS 
measurements, a probing system has been implemented on the firmware of 
an HP Broadband network analyzer. The system permits cell delay measure- 
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Table 1 Motion JPEG video clips statistics. 





medium 


large 


frame rate (sec“^) 


25 


20 


number of frames 


15000 


15000 


ave. frame size (bytes) 


6394 


14970 


min. frame size (bytes) 


2052 


7131 


max. frame size (bytes) 


13364 


45234 


std deviation of frame size 


2132 


4936 



ments from one network adapter to another with a precision in the order of 
microseconds. 

The cell level measurement system locks on a stream and measures the net- 
work QOS by injecting probe cells. Two probing methods were implemented. 
Both methods detect the beginning of a frame and then inject probe cells 
until the end of the frame is detected. The first method injects one probe 
cell every eight data cells. The second method injects a burst of twelve cells 
every sixty-four data cells. As the probes are interleaved with the video data 
streams, the QOS experienced by the probe cells should be very similar to the 
actual QOS received by the video stream cells. The second method allows for 
better cell gap loss measurements while the first for average cell loss. 



Experimental setup 

We have been using two Sun SparcStation 10 as our end stations. For trans- 
port, qStack (Huard et al. 1996), a native ATM protocol stack is used. Two 
motion JPEG and one MPEG-2 VBR video clips were used as multimedia 
streams. The motion JPEG clips are composed of 15000 frames and were 
recorded with different window sizes: medium (240x320 pixels) and large 
(480x640 pixels). The MPEG-2 video clip has 54020 frames (approximately 
30 minutes at 30 frames per second) with a window size of 296x720 pixels 
and GOP of 12/3. The statistics of the video clips are given in Tables 1 and 
2 . 

The network topology and the interference traffic streams are illustrated in 
Figure 1. The end-to-end video stream is generated by the workstation on the 
left. At the first hop (the Fore ASX-100 switch), the video stream is multi- 
casted to the second hop and to the broadband analyzer. Selective probing 
is performed by the broadband analyzer and probe cells are injected into the 
network. The probe cells enter the network at first switch and are multiplexed 
with the video cells. The probes and video cells are also multiplexed with a 
Poisson cell stream with an average of 20 Mbps. The Poisson stream is used to 
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Table 2 MPEG-2 VBR video clip statistics. 





I frames 


P frames 


B frames 


average 


number of frames 


4502 


13505 


36013 


54020 


ave. frame size (bytes) 


6657 


2886 


1945 


2573 


min. frame size (bytes) 


1062 


355 


322 


322 


max. frame size (bytes) 


16219 


14913 


15348 


16219 


std deviation of frame size 


4721 


4376 


1825 


2238 




Figure 1 Network topology. 



add some cell delay variation and to interleave the video cells so that they are 
not all consecutive. The combined flow (video cells, probe cells and Poisson 
cross traffic) goes through a set of four ATM switches and OC-3 links. At the 
Scorpio switch (in the middle), two cross traffic streams are injected: a con- 
stant bit rate (CBR) stream and a controlled bulk arrival cross traffic stream. 
The CBR stream is used to help filling up the queue at the contention point so 
that buffer overflow can occur more easily (77.5 Mbps CBR is injected when 
the medium window motion JPEG clip or the MPEG-2 VBR clip are played, 
and 74 Mbps CBR is injected when the large window motion JPEG clip is 
played). The controlled cross traffic consists of batches of cells injected into 
the network at line speed (155.52 Mbps). The batch arrival process is Poisson 
with an average arrival rate that can be set from 0.016 to 100 (i.e., mean batch 
interarrival time from 10 msec to 60 sec). The batch sizes are geometrically 
distributed with an average that can be set anywhere from 10 to 50 000 cells. 
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Figure 2 User frame loss for the MPEG-2 clip. 



The batch arrival rate and the average batch size can be changed dynamically 
to obtained different cross traffic load scenarios. Finally, at the last hop, the 
stream is demultiplexed. The probe cells are sent back to the broadband ana- 
lyzer for real-time cell level measurements of QOS, the video stream cells are 
sent to the workstation for reassembly, measurements and playback, and, the 
Poisson cross traffic is sent into the “garbage sink.” 



4 EXPERIMENTAL RESULTS 

Figures 2 and 3 show the frame loss and the cell loss for the MPEG-2 VBR clip 
under various cross traffic loads. Each curve corresponds to a constant load of 
the controlled cross traffic. Along the x-axis, the mean batch inter arrival time 
increases (the arrival rate decreases). To maintain a constant load, the average 
batch size is proportionally increased such that the ratio of mean batch size 
to mean interarrival time remains constant. 

Figure 4 shows the ratio of the frame loss to the cell loss. Each point was 
obtained by dividing the measured frame loss by the corresponding measured 
the cell loss. As can be seen from the figure, one can tolerate a cell loss larger 
than the one prescribed by Equation 1 since all the points in the figure are 
below 54, the ratio of average frame size to the cell size. Finally, Figures 5 
and 6 show the corresponding frame gap loss and cell gap loss of the MPEG-2 
clip. 

Similar graphs were obtained for the motion JPEG video clips. Figures 7 
and 8 show the ratio of frame loss to cell loss for the medium and large 
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ratio of frame loss to cell loss - medium mJPEG 




Figure 7 Frame loss to cell loss ratio for the medium motion JPEG. 




Figure 8 Frame loss to cell loss ratio for the large motion JPEG. 



window. As Figure 4 already indicated, one can tolerate more loss than Equa- 
tion 1 predicted since all the points on the figures are below the value of the 
ratio of average frame size to cell size, 133 and 312, respectively. That is, the 
prescription given by Equation 1 is too conservative by a factor of about 3. 
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5 RELATED WORK 

In Zitterbart (1996), a general framework for QOS management from user-to- 
user is presented. Simple mapping rules such as the one presented in Section 2 
are given. A QOS management system that performs QOS monitoring is also 
described. 

The one-to-one translation approach described in (Nahrstedt Smith 1995) 
and (Nahrstedt & Smith 1996) is comparable to our approach. It considers 
mapping between application and network level QOS and formulates arith- 
metic rules similar to the one proposed in Section 2. The main difference 
resides in the choice of QOS parameters. In (Nahrstedt & Smith 1995), a 
model for an endpoint entity called QoS Broker is presented. In (Nahrstedt & 
Smith 1996) the model is further developed to coordinate the end-system re- 
source management tasks: QOS mapping, admission control and task schedul- 
ing. Similar functionality is provided in the xbind broadband kernel (Chan 
et al. 1996) and (Lazar et al. 1996), but not addressed in this paper. The 
QOS broker of (Nahrstedt & Smith 1995) is comparable to the QOS manager 
referred to in (Zitterbart 1996). 



6 CONCLUSION 

In this paper, we have presented a framework for studying QOS mapping. 
As part of this research, we have developed a platform for evaluating end-to- 
end QOS by performing concurrent network, transport and application level 
measurements. The early set of concurrent QOS measurements have shown 
that the typical loss mapping rule given in the literature is too conservative 
by a factor of about 3. 

In order to obtain empirical QOS mapping rules, more data is being col- 
lected for future analysis. Furthermore, various network topologies and cross 
traffic patterns will be tested for validating the empirical mapping rules. Fi- 
nally, to test the sensitivity to the end-system behavior, we will carry out 
measurements using various implementation of user space transport protocol 
stacks (Huard 1996, Huard et al. 1996). 
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Abstract 

We describe an approach to transport QoS in unreliable networks that fo- 
cuses on tradeoffs rather than guarantees. In particular, we investigate trade- 
offs between qualitative QoS parameters such as order and reliability, and 
quantitative parameters such as delay and throughput. 



1 INTRODUCTION 

A traditional approach to quality of service (QoS) is to provide applications 
with guarantees for quantitative QoS parameters such as delay and through- 
put. However, when the underlying network is inherently unreliable, it may 
be difficult or even impossible to provide guarantees. Therefore, we focus on 
QoS tradeoffs between qualitative parameters such as order and reliability, and 
quantitative parameters such as delay and throughput. A major theme of our 
work is that there is “no free lunch”; improvements in reliability and order 
come at a cost of worsening delay and throughput. Our research has two goals: 
(1) to understand and characterize the nature of these tradeoffs via analysis, 
simulation and experimentation, and (2) to implement a transport protocol 
that provides the service user with as much flexibility as possible in selecting 
the best tradeoff for a particular application. Towards this end, we have in- 
vestigated partially ordered and partially reliable (PO/PR) transport service 
which provides flexible QoS tradeoffs to application designers and users. 



2 PARTIALLY ORDERED/PARTIALLY RELIABLE 
TRANSPORT SERVICE 

In a packet-switched network, the transport layer is the lowest layer responsi- 
ble for end-to-end QoS. Transport layer functions include: (1) recovery from 
data loss, (2) detecting and removing duplicates, (3) resequencing out-of-order 
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data, and (4) flow control/congestion avoidance. We view the level of service 
provided in each of these functional areas as a qualitative QoS parameter. 

PO/PR transport service Alls the gap between the extremes in service 
represented by TCP (ordered/reliable/flow-controlled) and UDP (unordered/ 
unreliable/not-flow-controlled). PO/PR service allows a user to avoid the un- 
necessary degradation in QoS parameters such as delay and throughput that 
may result if a service is used that is more strict than necessary (e.g., TCP.) 
Instead, PO/PR service can provide flow control, and the precise degree of 
order and reliability that an application requires — no more and no less. 

Our approach to providing PO/PR service is to implement it as a set of 
library routines (built over UDP) that applications can utilize to gain flexible 
control over the ordering and reliability of individual objects. This allows ap- 
plications to achieve an appropriate balance among various QoS parameters 
without having to reinvent the transport-layer wheel with every application. 
Such an approach is consistent with Application Level Framing as proposed 
in Clark & Tennenhouse (1990). Our results so far include analytic and sim- 
ulation results characterizing the QoS tradeoffs offered by PO/PR service 
(Section 3) and the development of software components for experimentation 
with PO/PR service (Section 4). 



3 ANALYSIS AND SIMULATION 

Analytic and simulation work has yielded several important results about par- 
tially reliable and partially ordered services (Marasli 1997). The key results 
related to partially ordered service are: (1) PO service provides buffer uti- 
lization and delay improvements over ordered service, particularly as the loss 
rate increases, or as the order requirements of applications decrease. Order, 
however, makes no difference to throughput, as long as the transport sender 
buffer size is less than or equal to the transport receiver buffer size (Marasli, 
Amer & Conrad 19976); (2) by carefully choosing the transmission order of 
independent objects (linear extension selection), additional buffer utilization 
and delay improvements can be obtained (Marasli et al. 19976, Marasli, Amer 
& Conrad 1996o). 

The key results related to partially reliable service are: (1) for lossy net- 
works, using a reliable transport service when only a partially reliable service 
is needed can cause considerable worsening in throughput and delay (Marasli, 
Amer & Conrad 19966); (2) both sender-based and receiver-based reliability 
schemes for providing partial reliability achieve almost identical reliability and 
delay. On the other hand, a sender-based approach provides better through- 
put than a receiver-based approach at higher ack loss rates (Marasli, Amer & 
Conrad 1997a). 
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4 EXPERIMENTATION 

Our empirical research into PO/PR service compares the performance of 

PO/PR protocols with that of traditional protocols, under a variety of net- 
work conditions. We have developed two client-server multimedia applications 

to test our notions about QoS tradeoffs: 

• A system for retrieving compressed images across a lossy, packet-switched 
network, allowing experimentation with various combinations of image 
compression techniques and transport protocols. This demonstration sim- 
ulates a hypothetical military communications system for transmitting im- 
ages of wounded soldiers for telemedicine or images of equipment such as 
tanks, airplanes, etc. for intelligence gathering (Amer, Conrad, Golden, 
Iren & Caro 1997). 

• A multimedia document retrieval system allowing authors to specify syn- 
chronization requirements, and varying degrees of reliability for multimedia 
objects. The basic model is similar to that of the World Wide Web; doc- 
uments are available on a server, and are retrieved with a browser. How- 
ever, unlike Web documents, these documents are temporal; they have 
a time dimension requiring synchronization of elements such as audio, 
video, still-images, text, pauses and interactions (Conrad, Golden, Amer & 
Marasli 1996). 

We have also built prototype implementations of two PO/PR protocols: 

• A:-XP provides an unordered, partially-reliable transport service 
(Amer et al. 1997). 

• Partial Order Connection, version 2 (POCv2) provides a partially-ordered/ 
partially-reliable transport service, and features for coarse-grained multi- 
media synchronization (Conrad et al. 1996). 

In support of future work, we are currently developing: 

• A library of transport functionality called the Universal Transport Library 
(UTL) . The UTL provides a generalized application programming inter- 
face to a number of different transport services with varying degrees of 
order and reliability. This allows a programmer to write applications that 
can be run over different transport services simply by varying a single pa- 
rameter at connection establishment time (Conrad 1997). 

• New versions of the compressed image and multimedia document retrieval 
systems based on UTL. With these applications, we can investigate the 
impact of QoS tradeoffs on the application as perceived by a real user, in 
addition to precise quantitative measurements of these tradeoffs under real 
network conditions (Conrad 1997, Iren in progress). 
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Abstract 

This paper looks at transport services required by applications and proposes 
using a QoS vector to specify all transport requirements. These ideas have 
been pursued in the design and development of a new transport protocol 
called Al. Preliminary performance results for A1 over ATM are presented 
and compared with an efficient kernel implementation of TCP/IP. 
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1 MOTIVATION 

Support for quality of service (QoS) - though much talked about - has been 
rarely implemented in computing environments. Recent developments are 
changing this outlook. The first is the emergence of Asynchronous Transfer 
Mode (ATM) which can support QoS on a per-connection basis. The second is 
the adoption and deployment of RSVP [Zhang93] by the IP community which 
allows applications to specify QoS parameters on individual flows. The third 
impetus has been the WinSock2 application programming interface which 
supports QoS on socket connections. This paper examines the issue of provid- 
ing realistic QoS support to applications at the transport layer. In contrast 
to the efforts above, a top-down approach is adopted in which application 
requirements form the main driving force behind the design. 

2 QOS AND APPLICATIONS 

Ideally an application programmer should not have to know the properties 
of a particular transport protocol and whether it is suitable for a given ap- 
plication. Instead it would be more appropriate if applications specified all 
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their transport requirements as a QoS vector which is then mapped by the 
system to a specific transport protocol and appropriate operating parameters. 
This would be beneficial in many ways. Firstly, new transport protocols can 
be seamlessly added to the system without the need to inform application 
programmers and there would be no need to recompile or relink programs. 
Secondly, the transport requirements of an application may be mapped to 
several protocols on a given site. The system may choose a given transport 
protocol based on the requirements of the application, the types of networks 
to which it is connected and the transport protocols available at remote sites. 

The ability to dynamically change the quality of service on a transport 
connection is becoming a much desired feature of transport services [Pope97]. 
However, it may be preferable not to involve the network every time there is 
a change in QoS. When a connection is being set up, the maximum QoS is 
determined and these parameters are submitted to the network layer. Once 
these parameters have been agreed the QoS can be changed at the transport 
layer without notifying the underlying network if the proposed change is less 
than or equal to the agreed maximum. A transport QoS vector is proposed 
below. 



typedef struct qos { 



uchar 


sort 


uchar 


coptions 


ushort 


max_alloc 


uint 


max-data-T 


uint 


max_data_t 


uint 


max-data_inrate 


uint 


max-dataJnburst 


uint 


max_data_outrate 


uint 


max_data_outburst 


uint 


maxJatency 


uint 


max-jitter 



} MAXQOS, *pMAXQOS; 



The sort field specifies the priority of this transport connection with regard 
to other connections in the system. The coptions field is a bit field that is 
used to set the properties of the connection. The properties are: 



DATA.CHECK 

RETRAN 

MBP 

RJ 

FASTCLOSE 

UNI 



- checksum the data on this connection 

- ask for a retransmission if data is lost or corrupted 

- preserve message boundaries 

- restrict jitter: explained below 

- close when the other end wants to close 

- data transfer in one direction only 
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Figure 1 Throughput Measurements 



For applications sending messages to each another, setting the MBP bit en- 
sures that receivers get each individual message separately. The FASTCLOSE 
option is used to quickly terminate a connection once the other side has indi- 
cated that it would like to close the connection. The tWJ option indicates that 
all data transfer will occur in one direction only. For some applications, getting 
the most recent data to the remote end as soon as possible is of paramount 
importance. In the Restrict Jitter mode, the message at the head of the receive 
buffer queue is deleted to provide space for incoming data when the queue is 
full. So the receiver gets the most current data even in overload conditions. 

The max_alloc field specifies the maximum number of outstanding mes- 
sages that the application would like to have pending while max_alloc_r and 
max..alloc.t specify the maximum receive and transmit message sizes respec- 
tively that the application expects to deal with. These parameters are used 
to allocate the necessary buffers for the connection and to set the fiow control 
window size. The next four parameters set maximum values for the rate and 
burst in the inward and outward directions. For a normal connection, both 
rate-based and windowing fiow controls are specified. In the restrictjitter 
mode, there is no windowing fiow control - though rate-based control is en- 
forced. 
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3 THE A1 TRANSPORT PROTOCOL 

To test some of the ideas presented in this paper, a user-level transport proto- 
col, called Al, which supports different qualities of service was designed and 
implemented. Some preliminary performance results are given below. The 
tests were done using two Pentium Pros (199 bogomips/256M) connected 
via an ATML Virata Switch using Efficient Networks, ENI-155 Mbits/s PCI 
adaptor. Both machines were running Linux 2.0.25 with Werner Almesberger’s 
Linux- ATM release 0.26. For the Al implementation 40-byte E164 addressing 
was used. The tests consist of sending a large amount of data but using block 
sizes up to 16K in length and measuring the throughput of the system. 

Figure 1 shows the results for raw AAL5 SVC, classical TCP/IP or CLIP 
over ATM and Al with and without retransmission. For the AAL5 mea- 
surements, a switched virtual circuit was set up, using the ATM-UBR QoS 
traffic class. A 1Gbyte burst was sent and the throughput was measured for 
a 100 Kbyte sample. The plot shows a rather linear rise in throughput to 135 
Mbits/s with the knee of the curve appearing at a block size of 1.7Kbyte. For 
CLIP a 10 Gbyte stream was used with the average throughput measured over 
the whole stream. This test program was compared with and gave identical 
results to ttcp. The same test program was used to drive Al. For CLIP, a 
throughput of 130 Mbits/second was achieved. 

For Al with retransmission (Al RETRANS) the throughput was measured 
over a 1Gbyte stream. A 9Kbyte network block size was selected to make a 
valid comparison with CLIP. The graph slowly climbs to about lllMbits/s 
with a fall as the send block size exceeds the network block size. With Al 
without retransmission (Al RAW), the throughput climbs on a similar curve 
to Al RETRANS but continues upward to about 130 Mbits/s before falling 
once the send block size reaches the network block size and then rising again 
to a level close to the raw ATM throughput. 



4 CONCLUSIONS 

We think that the approach taken in this paper will lead to better transport 
services. 
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Abstract 

The panel discussed the current state and likely future development of how to pro- 
vide differentiated quality of service in an Internet context, primarily through reser- 
vations. The panel agreed that it appears unlikely that a single approach will fit all 
applications, with different trade-offs between complexity, level of guarantee and 
scaling 
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FRED BAKER 

Applications that need QoS include network telephony, teleconferencing, interactive 
applications, transaction applications, SNA in TCP/IP. QoS may entail controlled 
latency, dedicated bandwidth or improved loss characteristics. QoS can be improved 
by a combination of QoS routing, line protocols and queueing. 

For QoS routing, getting better service is a matter of getting an appropriate route, 
using for example, OSPF TOS routing, IS-IS, ATM PNNI or future protocols such 
as QOSPF. QoS routing has been discussed periodically, is now the subject of a new 
IETF working group, but has historically not been important outside of specialized 
networks. 

Line protocols such as ATM and multilink PPP are the second approach to im- 
proving QoS. ATM allows to multiplex traffic streams at high speed, with different 
virtual channels (VCs) for different services. Multilink PPP is able to “interrupt” 
traffic on (typically) low-speed lines, giving preference to some types of traffic. For 
ATM, we can either have a common or separate virtual channels. For separate VCs, 
an edge device routes traffic on VC with appropriate set of characteristics, so that 
each VC contains a set of flows through a given set of neighbors with matching QoS 
requirements. For the case of a common VC, one VC is used for a given set of neigh- 
bors, requiring advanced queueing at the edges and a VC service comparable to the 
needs of the flow with the most stringent QoS requirements. 
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Panel II 



PPP multilink fragmentation is used for low-speed circuits, typically T1 and be- 
low. Here, the goal is that big messages should not delay small, delay sensitive mes- 
sages such as voice traffic. PPP multilink defines a message fragmentation mecha- 
nism that splits large packets into smaller fragments, with a special encapsulation, 
which can be used across several or a single link. The scheme suffers from line and 
segmentation/reassembly overhead. 

The third approach to improving QoS is to employ non-FIFO queueing, based on 
the premise that getting better service is a matter of managing congested queues. The 
total latency and bandwidth across all flows are constant, but we make some traffic 
absorb latency and therefore give up bandwidth, shielding other traffic from latency 
and letting it gain bandwidth. 

QoS-aware queueing algorithms can be divided into two classes, congestion man- 
agement and congestion avoidance algorithms, with priority, class-based (custom) 
and weighted fair queueing (WFQ) examples of the former and random early detec- 
tion (RED) an example of the latter. Priority queueing is commonly implemented, 
e.g., triggered by IP precedence bits or access lists. If not well engineered, it can 
cause traffic lockout; within each priority class, packets are served FIFO, with un- 
predictable QoS. Class-based queueing achieves a guaranteed rate or latency for par- 
ticular classes of traffic by some variation on round-robin queueing, with a limit on 
the number of bytes removed from the queue at each round. Weighted fair queueing 
achieves predictable latency and bandwidth for reserved flows. In WFQ, the multi- 
plier on the message length has flows share bandwidth predictably unfairly. WFQ 
requires more sorting than the other algorithms. For TCP, weighted random early de- 
tection can discriminate between flows, thus achieving congestion avoidance rather 
than congestion management. Traffic is dropped in proportion to mean queue depth 
and time since last discard. RED is still FIFO queueing, with no predictable QoS, 
which depends on host TCP behavior (throttling) for effectiveness. 

Currently, RSVP can be used to set up either guaranteed flows, offering guaranteed 
delay by guaranteeing bit rates, or controlled load flows, with a simpler design for 
adaptive applications. Unused capacity is left for best-effort traffic. RSVP services 
can be offered in broadcast networks through a subnet bandwidth manager where 
flows ask for permission. For ATM, guaranteed service maps roughly into CBR, 
controlled load service into VBR and best-effort traffic into ABR or UBR. RSVP 
does not work well for many small reservations and is likely to be proven in corporate 
networks before it reaches the Internet backbone. 

RSVP is one of the answers for QoS-enhanced traffic; it is not the only one. For 
voice-over-IP, I recommend using IP precedence - imagine 38,000 RSVP sessions 
on an OC-12. IP Precedence is also going to be used in the backbone in the near 
term, as it is simple and lightweight, scales and affords administrative control. How- 
ever, it suffers from a lack of admission control and a coarse selection of weights. 
On the other hand, for unengineered edge networks and for large flows, RSVP is a 
reasonable answer. 
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JONCROWCROFT 

Providing a given QoS can be done in a number of ways, essentially reflecting the 
time scales over which investment is made on behalf of a user, or set of users. Three 
points on this spectrum of ways might be: 

Over-engineering selected paths: In traditional circuit switched networks, a circuit 
set up on demand is a version of this, albeit less flexible than a virtual path by 
multiple circuits, which can be shared. In an Internet, a particular route could be 
overprovisioned; that route might be shared by multiple networks as well as users, 
hosts or applications. 

Subscription for selected terminals or addresses: A virtual private Internet offer- 
ing improved QoS can be created by assigning resources based on address pre- 
fixes or IP network numbers. Flows from and to such sites receive preferential 
treatment via precedence or fair queueing. 

On demand: Here, a virtual circuit or flow is set up using a signaling protocol, call 
admission control (CAC), traffic policing, traffic accounting, and service discrim- 
ination through scheduling. 

As we progress down the spectrum, and through time in the evolution of multiser- 
vice networks, we find increasing costs and difficulties in deploying the necessary 
technology. We find contradictions between the requirements brought on by new 
technology, and our solutions to prior parts of the networking problem. Prime exam- 
ples of these are 

• receiver driven multicast, and traditional sender based signaling; 

• resource reservation and QoS routing; 

• open signaling for multi-metric QoS, and open network provisioning (e.g., how 
do a set of providers on a set of paths get to share out a delay budget); 

• on the fly re-negotiation and IP Security ; 

• mobility and route pinning. 

It is my contention that the costs of solving these problems outweighs the ben- 
efit, and that the balance should be redressed towards the simpler end of the QoS 
provisioning spectrum. 



ROCH GUERIN 

The main issue is: what is driving the need for reservations? It is not (mostly) the 
requirements of various multimedia applications. In the same fashion that video- 
conferencing is not the killer application, there is no single application that is so 
critical and has so unique requirements that the only way it can be supported is by 
making reservations. Or the other way around, there are so many applications with 
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so many unique requirements, that it is impossible to define a reservation framework 
that will make them all happy. So, forget about the feasibility, suitability, applicabil- 
ity, etc. of reservation models. 

The main driver is that as the Internet moves more and more towards a commer- 
cial network, people want to know exactly what they are paying for. In particular, 
business and commercial customers who rely on the Internet for critical parts of 
their business want guarantees on the level of service they get. As a result, the need 
for reservations is driven largely by the need for enforceable and observable service 
contracts. So, any reservation model where I can easily check and specify what I’m 
paying for will do. 

Given that enforceable and observable contracts are a main driver, the next issue 
is what kind of (reservation/service) contracts are likely to emerge. 

I contend that deterministic or pseudo-deterministic contracts are much easier to 
deal with. Hence, a service such Guaranteed Service should actually be easier to 
offer than a “fuzzier” one such as Controlled Load. This is certainly not to say that it 
is easier to implement, but if an important requirement is verification of compliance 
with the contract terms, deterministic services will prevail. 

Similarly, a hard-line usage parameter control such as the ATM UPC represents a 
much simpler and cleaner mechanism on which to base a contract. Allowing excess 
traffic above and beyond what is specified in a contract, not only adds quite a bit of 
complexity in the infrastructure, but also makes for much fuzzier contracts. 

Again, this is not to say that there is no need for other types of service offerings 
and contracts, but their evolution will largely depend on future economic trade-offs. 
For example, if link and switch/router bandwidth become a cheap commodity, then 
only some trivial traffic contract will be needed (CBR-like). This is very much like 
what’s happening with applications in terms of memory and CPU requirements, now 
that these resources are less and less constrained. So, the evolution of traffic contract 
will also be driven by the interactions between customer requirements and the cost 
of network resources. This is, however, likely to be a gradual process. 

To summarize, economic and contractual factors are what is driving the need for 
reservations. This argues, at least initially, for simple and deterministic services and 
contracts. Economic factors such as cost of resources and their exploitation will be 
the important drivers, but are many conflicting forces, e.g., cheap resources lead to 
simple signaling, where value is added at end-systems and not by service providers or 
equipment vendors. If resources are expensive, a network needs complex signaling, 
thus leading to providers and equipment vendors adding most of the value. 

So, where are the incentives and who will push for what? 

Maybe with good caching in the servers, the only reservation mechanism I need is 
a circuit-switched network k la ISDN. . . 
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Service Models 

In any communications network, an expectation of a “standard service” will emerge, 
similar to 64 kb/s voice channel for telephony and the 16 to 24 kb/s or so effective 
modem throughput. Standard service cannot require reservation, in the sense that 
there is any likelihood of being denied that service. For customers with access band- 
width, standard service will be equal to the access bandwidth or a substantial fraction 
thereof, just like the telephone network. Internet telephony and RealAudio-style low- 
bandwidth continuous media are likely to be considered standard services. 

The existing consumer ISP model is based roughly on a multiplexing model where 
200-300 concurrent users share a Tl, and 10-15 customers share an ISP line. With 
Internet telephony, radio-like services and content “pushing”, the $20/month model 
is no longer sustainable. However, this not imply that reservations are appropriate, 
rather that volume-based charging may be instituted. (Already, the $20/month is typ- 
ically silently limited to less than 8 hours/day.) In some cases, crude distance differ- 
entiation (domestic vs. transoceanic) may be appropriate to encourage use of local 
multimedia caches. 



TVaffic Scheduling 

As mentioned elsewhere in this note, three possibilities of scheduling traffic are com- 
monly discussed. It is fairly straightforward and instructive to compute their end-to- 
end delay bounds D for a network with h = 10 hops, connected at a rate r = 622 
Mb/s (OC-12). Assume that the maximum packet length Z* is 1500 bytes, while the 
flow of interest is packet voice with a packet length of 80 bytes and a rate of pi = 16 
kb/s. 



Priority: 

WFQ for individual flow: We assume that voice flows have a leaky-bucket depth 
of zero (i.e., are CBR). 



D = ^ ^ -f /i— =z 360 ms 
Pi r 



WFQ for all voice flows: Assume that voice traffic makes up roughly half of all 
Internet traffic, for pa = 300 Mb/s. We need to allocate a bucket depth to 
accommodate the case that all voice sources inject their packet at the same time. 
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Note that this model does not preclude individual admission control for each voice 
stream, although this seems unnecessary. 

D = h (/i — 1)^ h h— = 4.0 ms 

pa pa ^ 



Priority for voice: Due to cross-traffic, a voice packet may have to wait for a burst 
of other voice packets at every hop. 



D = = 193ms 

Unfortunately, these delay bounds are fairly meaningless for delay-adaptive ap- 
plications, where measures such as a 99% percentile of delay are more predictive 
of perceived performance. In particular, the upper bound for priority is extremely 
unlikely. 



Resource Reservation Protocols 

Thus, for reasons of service expectation and scaling, as Fred Baker pointed out 
above, the use of RSVP for each Internet phone call is unlikely, but the ability to 
use RSVP to set aside a given fraction of the bandwidth for IP packet marked with 
type-of-service (TOS) bits may well turn out to be useful, as it alleviates some of 
the starvation problems of priority queueing. It should also be added that, due to its 
predictable per-flow bandwidth and anticipated large volume, Internet telephony is a 
rather good candidate for priority queueing. 

Initially, RSVP was perceived as a light-weight reservation protocol, as compared 
to, say, ATM signaling. However, a number of factors have made the final product 
far from simple. Among these are 

flow merging: It is not yet clear that multiple classes, with fine-grained parameters 
are truly needed, as most applications can probably be fit into a relatively small 
set of bandwidth classes, say, increasing at factor-2 or factor- increments. Flow 
merging also necessitates introduction of a “blockade” state to prevent killer reser- 
vations. 

receiver orientation: In some cases, receivers have no direct knowledge as to the 
bandwidth to be delivered by the sender and, due to large-scale multicast, senders 
have to guess in any event what their intended audience can support. The sepa- 
ration of reservation and path-finding messages for receiver-oriented reservation 
mechanisms imposes additional processing and protocol complexity, 
receiver diversity: At least for bandwidth diversity, reservations are an inappropri- 
ate means to distinguish classes of receivers as random packet dropping to thin a 
stream is usually not useful. In addition, other mechanisms such as layered multi- 
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cast were found to be superior. In networks with sufficient bandwidth where each 
flow consumes only a small part of the total capacity, queueing delays should be 
only a 

application modification: Applications need to be modified to take advantage of 
resource reservation, or an external agent needs to be added, both incurring com- 
plexity. 

For many applications, particularly multicast delivery of streaming content, a sender- 
based approach may offer greater simplicity. Receiver diversity in bandwidth or la- 
tency requirements for each flow are not relevant here. (This also avoids the prob- 
lem of receiver-based charging for multicast reservations, which encourages smart 
receivers to wait until a neighbor has paid for the bottleneck and then drop the reser- 
vation.) 

One particular sender-based approach that we are studying is to use RTCP and 
router-alert IP options to do either burst or flow reservations, with no additional pro- 
tocol overhead and automatic bandwidth-scaling. (We blithely assume that proto- 
col layering violation is no longer a federal offense punishable by having to read a 
binder’s worth of ITU documents.) 

It appears likely that we will see a range of QoS mechanisms, both for traffic 
scheduling and setting up state, with different trade-offs between QoS predictability, 
granularity, scaling and . RSVP may end up being primarily used to “nail down” 
virtual private networks, with somewhat better set-up latency and fault recovery ca- 
pabilities than manually doing this via SNMP. 



LKIA ZHANG 

The Internet needs to provide services differentiated in quality now and in the future, 
just like other industries. That is not so much because some applications need a 
better QoS than others (just like living: you take what you can afford) but more 
fundamentally it is needed due to economic reasons. 

Christian Huitema has said WHERE: “Giving everyone the very same service, as 
we do in the Internet today, has a definite economical consequence, a price war, that 
leads towards ’dirt for cheap’. If we want to pour money into the network so we can 
actually build it, we must make sure that whoever pays more gets more.” 

Differentiated services mean different packets get treated differently, and that in 
turn means some state inside the network. Given the necessity for state, the question 
becomes how to set up and maintain that state. Indeed, one could always do every- 
thing manually (say, using SNMP to set up class-based queueing (CBQ) state at each 
node), but using an automated protocol seems a much better way. 

Within the above context, the amount of state and the frequency of state changes 
are engineering decisions, depending on whether it is cheaper to have less (coarse) 
state and more provisioning, or one needs a tighter control. Examples for the former 
include the unengineered edge links mentioned by Fred Baker, while intrinsically 
low bandwidth links such as wireless or modem links fall into the latter category. 
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Abstract 

In multimedia systems, session coordination technique is important to ac- 
commodate a new session and re-distribute reclaimed resources when tough 
continuous media session is exiting. Although end-users do not want to specify 
the quality of service (QOS) in an exact memory size like in KB or KB/s of 
bandwidth, such rigid usages are necessary for admission control and coordi- 
nation. Therefore, we introduce the multi-level quality specification and QOS 
translation mechanism to put it into the quantitative expression which the 
system can handle. Nonetheless, session coordination have demanded compli- 
cated computation or presented an NP-complete problem. Constraining QOS 
specification, we invent a simplified session coordination method which is fea- 
sible enough to actually implement. This paper reports experiments on QOS 
translation and multiple session coordination using the Conductor/ Performer 
system on top of Real-Time Mach 3.0. 

Keywords 

real-time processing, microkernel, middle- ware, QOS control, continuous me- 
dia, distributed system 



1 INTRODUCTION 

Quality of service (QOS) management is the indispensable feature in mul- 
timedia systems. Although several QOS management systems are proposed, 
we have not yet met the definitive one. Some proposal might be a mere de- 
sign framework without any working implementation, the others might offer a 
fancy power of expression but force a complicated and/or even NP-complete 
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computation. Here we explain our QOS control middleware which equipped 
with QOS translation mechanism and a simple method for dynamic QOS con- 
trol. This enables us to exchange QOS quantitatively and predictably between 
sessions and to discard ad hoc system stabilization so far. Furthermore, the 
session coordination method is simplified by introducing a monotonic con- 
straint into QOS specification. This makes it feasible to actually implement. 

In the next section we survey related work, then we introduce our QOS 
specification in section 3, QOS translation framework in section 4 and our 
simplified session coordination technique for dynamic resource re-distribution 
in section 5. Our system is based on Real-Time Mach 3.0 microkernel and the 
middleware called Conductor/ Performer system(Keio-MMP Project WWW 
1996, Nishio ei ai 1994), which is briefly explained in section 4. Section 6 
reports experiments on multimedia session coordination using actual resource 
usage measurements, and then section 7 offers some concluding remarks. 



2 RELATED WORK 

In resource management for QOS control, Microsoft’s Rialto( Jones ei al 1995) 
presented a QOS reservation framework for multiple types of system resources. 
There, a resource planner is centered to manage multiple sessions resource 
coordination. However, any results of actually running system were not pre- 
sented, and no refer to any QOS translation concept we are interested in. 

Although Kawachiya at TRL(Kawachiya ei al 1995) presented an actual 
timing result of QOS controlling, it only refers to a processor cycle resource. 

Tokuda’s research(Tokuda ei al 1993) tries to manage multiple multimedia 
sessions. This control mechanism is active and each thread applies it to itself. 
This self-stabilization method might not balance resource reclaiming among 
sessions. Since ordinal multimedia session states would change discretely, a 
mere simple up-and-down of video frame-rate might damage the overall per- 
formance. Especially, a decision of when and how much a session should 
be upgraded is a hard problem. If failed, not only system instability but also 
overall system overload might happen. 



3 QOS SPECIFICATION 



3.1 C haract er ist ics 

QOS specification should be used for predictable multimedia systems. This 
is utilized for admission control at the session creation, resource reservation 
and resource re-distribution at the dynamic QOS control. This specification 
is characterized as the following features: 
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• QOS specification is usually discrete and ranged, 

• QOS specification has some dimensions, 

• objects which are specified have a hierarchy, 

• preference between objects is necessary, and 

• specification has multiple levels of expression. 



First, mainly because of the constraints of devices, QOS specifications are 
usually discrete and have its upper and lower limits. For example, a video 
playback at 12 fps is meaningful but playback at 12.3 fps is not. Some device 
might only have functionality to capture image at 160x120 or 320x240. This 
aspect should be regard as not that every specification is discrete, but that 
we can not always expect continuity in specifying QOS. 

The next aspect refers to QOS dimensions. In our system, it is expressed in 
two-dimension: temporal quality and spatial quality. Temporal quality con- 
cerns video’s frame rate or audio’s sampling rate, while spatial quality ex- 
presses video image size, color-depth bit length, or audio quantization bit 
length. In future, we plan to add timing accuracy quality, i.e. presentation 
delay, jitter bound, inter-stream synchronization etc. 

The third aspect of objects hierarchy means that a user specify a movie 
session as a certain quality and the movie session consists of video and audio 
stream. The video stream might consist of a storage access component, data 
transport component, compression/ decompression component and viewing 
component. It is important to clarify which object is specified by its quality. 

As the fourth aspect, inter-object constraints of user’s preference is neces- 
sary. For instance, some user may want to prioritize audio stream more than 
video stream. Some may regard the session which has the front-most win- 
dow should be most prioritized. The upper-most component of a data stream 
would dominate the constraints of the other components in the same stream. 

The last aspect of multiple-level expression is explained in the next section. 



3.2 Multi-level QOS Specification 

In multimedia systems, QOS specifications are important for admission con- 
trol and dynamic resource re-distribution. The nature of such specifications 
has multiple levels of expression. End-users do not want to know details of 
system resources like CPU, memory, network bandwidth, etc. They may want 
to specify a movie playback quality in an abstract way like good/fair/poor. 
For middleware, it has to analyze the specifications of selected movie file or 
video camera devices and should use more rigid expressions like 320x240 pixel 
image, 15 frames per second. On the other hand, systems which have responsi- 
bility for admission control, resource reservation and dynamic re-distribution, 
should obtain quantitative information of resource usage for the movie play- 
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Table 1 Three-level QOS characteristics 





Expression 


User 


Example 


ULQ 


abstract 


end-user 


good/fair /poor 


MLQ 


H/W independent 


middleware 


24fps, 22kHz 


SLQ 


quantitative 


kernel etc. 


18%, 20MB/S 



back. They need specific physical memory size or network bandwidth, the 
usage values of which should change from platform to platform. 

We introduce three-level expression of QOS specification. They are User- 
Level QOS (ULQ), Middleware-Level QOS (MLQ) and System-Level QOS 
(SLQ). ULQ is introduced for the end-users, which is expressed in an abstract 
way like good/fair/poor. MLQ is for middleware-level software for continuous 
media processing. MLQ has more concrete expression of the QOS than ULQ, 
for example, 15 fps, 16-bit color, 44.1kHz stereo sampling etc. MLQ should 
be expressed in hardware platform independent descriptions. The difference 
between ULQ and MLQ is that MLQ determines an unique QOS of the session, 
but ULQ does not. Translation between ULQ and MLQ would be usually done 
in the middleware and/or library linked to an application program. 

SLQ is used by kernel, resource manager, admission controller and session 
coordinator. They should be expressed in rigid expressions like physical mem- 
ory size and network bandwidth. SLQ contains hardware platform dependent 
information. They are used for admission control and dynamic resource re- 
distribution in the session coordination. Translation between MLQ and SLQ is 
usually done by middleware (session server, resource manager etc.) or kernel. 

Table 1 shows the characteristics of those three specifications. 



3.3 QOS Path 

Assigning a single QOS specification for a session leads the system to less 
reactive and less flexible situation. In order to perform dynamic QOS control 
or resource re-distribution efficiently, multiple QOS states per session should 
be nominated. Therefore, we introduce a concept of QOS path, which bundles 
user-admissible QOS states. Every QOS state is totally ordered to form user’s 
preference. Usually the top-most state has the maximum QOS and the bottom 
one has as low QOS as possible. QOS path is an abstraction of a ordered set 
of QOS possible states in the user-admissible range. 
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4 QOS TRANSLATION 

In this section, a brief explanation of our middleware is presented first, then 
the QOS translation mechanism for it is explained. 



4.1 Middleware Architecture 

Before explaining QOS translation mechanism, we must present a brief overview 
of our software platform. Our middleware is called Conductor/ Performer ar- 
chitecture, which is a set of system servers and libraries developed on top of 
Real-Time Mach 3.0 microkernel. 

Conductor is responsible for session management, QOS/resource manage- 
ment and media synchronization. Performers are dedicated in media specific 
processing; i.e. a file service performer accesses media data directly to/from 
storage devices, a display performer fetches image data and draws it to a win- 
dow. User requests conductor for session creation, then conductor negotiates 
with applicable performers and reserves proper resources. Once a multimedia 
session is established, a real-time thread is generated in conductor and sends 
IPC’s to performers in order to synchronize their activities. All data transfers 
through the shared memory buffer (called Cyclic Shared Buffer; CSB) among 
conductor and performers. 

A conductor session consists of one or multiple streams. A stream repre- 
sents a flow of a single type of medium which does not branch. For example, a 
movie session consists of a video stream and an audio stream. Each stream is 
an abstraction of a series of performers. A video stream which displays video 
frames from a disk storage into a window would be a series of a file performer’s 
session and a display performer’s session. 

Conductor may delegate the actual system resource reservation and/or en- 
forcement to appropriate entities; processor reservation for microkernel(Mercer 
et al. 1994) or external dedicated servers(Kawachiya et al. 1995) and stor- 
age/network bandwidth for storage/network performers(Kihara ei al. 1993). 



4.2 QOS Translation Mechanism 

In the first place, an application program makes a user to select the User- Level 
QOS (ULQ) for a session via GUI or some other interface. Our toolkit library 
helps users to include the following things: 

• priority of the session among the existing sessions, 

• priorities of streams in the session, 

• priorities of QOS dimensions in the stream, and 

• admissible QOS range of each stream 
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First three items are specification between objects(sessions, streams and 
QOS dimensions). Especially, session priority is the most important, since 
this is used in a victim selection algorithm for session coordination. Stream 
precedence specifies which stream is more important for the user, for exam- 
ple, video or audio. These priority may change dynamically. We assume the 
following cases of priority change: 



• user’s command is issued, 

• the newly created session should be prioritized the most and 

• some window manager which detects the front-most window at that point 



The fourth one is given in an abstract way. Our system uses such an ex- 
pression as max, medium, any. Max means the user satisfies only with the 
maximum QOS. In this case, QOS path becomes only a single and maximum 
QOS state. Medium means a user admits the QOS degradation by medium. 
Any means that he/she does not complain at any QOS. 

Since users, of course, specify what a source of stream is (i.e. video camera, 
a name of movie file etc.), the conductor can know the maximum QOS by 
asking the source performer. Conductor then translates ULQ expression into 
a more concrete expression called Middle- ware- Level QOS (MLQ). First, it 
asks the source performer the available QOS ranks for that stream source. For 
example, it gives a movie file name to the QuickTime file performer and ask it 
available QOS-ranked sets of image size, color-depth, frames per second. This 
set of ranks of service is an MLQ expression. Conductor generates a QOS path 
based on this. This QOS path expresses the maximum and minimum range 
of stream QOS. This is the first phase QOS translation from ULQ to MLQ. 

Then, the QOS path of MLQ is passed to each performer to examine the 
necessary resource usage performers actually require, since the corresponding 
performers only know their activities’ physical cost. Therefore, it is desirable 
for performers to provide conductor with (i)multiply-QOS-ranked services as a 
QOS translation table and (ii) capability to calibrate cost-estimation for differ- 
ent hardware platforms.Our system’s QOS translation table is created off-line. 
Each performer has a service to calibrate the table according to the hardware 
platform. Among our performer interfaces, the c/ass.name_openj5ession ser- 
vice call has a passing-argument of MLQ specification and returning-argument 
of physical resource usage required. This physical resource usage can be called 
System-Level QOS (SLQ), which is expressed in processor cycles, physical 
memory size, or storage/network bandwidth. At this time, conductor could 
complete the second-phase translation from MLQ into SLQ. This enables con- 
ductor to admission-control of new session and session coordinate quantita- 
tively. Session would never be created when conductor decides it is impossible 
to afford such a QOS range. Figure 1 shows how ULQ is translated into SLQ 
in our system. 
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I User Application Program I User-Lev«l QOS 
' 1 ^ {Max, Half, Any} 



Conductor 



stream_set_qos(..., stre^_spec, ...) 



Middle-waro-Uv«l QOS System-Lev«l QOS 

{Frame rate. Image size, {Processor,^Storage, ...) 



performer_open_session(..., session.spec, &resource_spec, ...) 



{10 fps, 320x240. 8-bit color, ...} 



I Performer | 



), 8-bit color, ...} ^ ^ 

J 

{CPU:10%, Dlsk:750KB/s, ...} 



Figure 1 QOS Translation Flow 



5 SIMPLIFIED ALGORITHM FOR SESSION COORDINATION 

Conductor’s session coordination which will require resource re-distribution 
is triggered when: 

case 1 A new session creation is requested, 
case 2 A running session is exiting, 

case 3 A user requests a QOS change or a performer up-calls the QOS change 
necessity and 

case 4 transient over-load is supposed to occur according to the information 
collected by a deadline handler of conductor threads. 

Then conductor triggers QOS management in the following sequence: 

1. victim session selection, 

2. calculates deltas of SLQ by QOS-state-transition along QOS path, and 
examines possibilities of resource re-distribution, 

3. executes QOS-state-transition of existing sessions, and 

4. reserves resources for a new session, if necessary. 



Our victim selection method is quite simple since (i)it is organized only 
by the session precedence and (ii) we constrain each QOS path must be 
monotonic. The session precedence is the total order of existing sessions. In our 
conductor, by default, the most recent session becomes the most important. 
Users can also specify a session importance explicitly. The monotonic QOS 
path constraint means that as follows. QOS possible state in SLQ can be a 
vector of each type of resource usages. These vectors in the QOS path are 
ordered monotonically decreasing or increasing, i.e. each element is less than 
or equal to the element in the upper vector in the QOS path. This constraint 
makes resource usage computation quite simple. 
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Figure 2 QOS Path and Precedence 



Thus victim session can be selected from the session precedence, the lowest 
session in the sequence. After the victim session’s QOS is decreased by one- 
hop, if the reclaimed resource can not accommodate the resource scarcity, the 
second lowest session is the next victim. The monotonic constraint of QOS 
paths makes the resource usage computation much easier. 

Although there is an alternative policy to decrease the lowest session by 
two-hop, we do not adopt this, since this policy is suitable for the rather high 
prioritized sessions. This tends to decrease the number of existing sessions and 
increase the QOS of them. We call this policy individual-first. We adopt the 
policy to decrease the QOS of existing sessions and increase the number of 
them. This policy is called welfare-first. 

Therefore, all sessions should be separated into two groups in order to 
change the policy to reclaim the resource usage. We name the line which 
separates the sequence of session precedence into two groups welfare bound 
line; sessions higher than the line are in the individual-first group and other 
sessions are in the welfare-first group. Sessions in the individual-first group 
always seek the highest QOS possible using all the available resources in the 
precedence order. They don’t care for sessions lower than themselves. They 
might force lower sessions to give up to run. Sessions in the welfare-first group 
seek to preserve or increase the sessions running alive even if their QOS should 
be minimized. If total number of running sessions gets increased, a higher 
session might give up to run for lower sessions. Since the number of individual- 
first sessions are determined by the hardware potential, actually it would be 
one or none, in which case all sessions are in the welfare-first group. 

Figure 2 depicts the session precedence and QOS paths. 
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Figure 3 Experiment System 



6 MULTIMEDIA SESSION COORDINATION EXPERIMENT 

We used a hardware platform of Toshiba’s Pentium 90MHz sub-note machine 
with 16MB memory and C&T’s 65546 graphics chip on VL-bus architecture. 
We prepare two performers for this experiments: QuickTime File Performer 
(qtfp) and MMP-X Display Performer(mmpx). 

Qtfp assumes the constant rate storage access server such like CRAS(Tezuka 
ei al 1994), and simulates such services using memory-mapped file. Although 
this performer consumes large physical memory, this makes its behavior pre- 
dictable and suitable for such an experiment. Qtfp can parse Apple’s Quick- 
Time movie file and clients can fetch an image frame of any time stamp at 
the same resource cost through our performer interface. For this experiment, 
we prepare QuickTime files each has a video track of 50 frames of 8-bit color 
images but differently sized at 160x120 and 320x240. Qtfp can be enforced to 
limit its data transfer rate as client specifies using periodic thread or processor 
reservation mechanism. Figure 3 shows the system overview. 

Mmpx is a performer which we enhanced the X server from XFree86 v.3.1.2. 
We made a Mach-IPC port for real-time services besides normal socket- 
interfaced X services(Tada 1994). Since this service port is always prioritized 
to normal socket port, we can guarantee X server’s predictable behaviors. In 
addition to this port, data transfer is done through a shared memory, which 
completely eliminates image copying and realizes quick image drawing. 

All time measurements are done by fetching Pentium’s free-running cycle 
count register, calibrated with its processor cycle. 

Our experiment uses three sessions playing QuickTime file into an X win- 
dow at the User-Level QOS given in table 2. These QOS specifications are 
translated into Middle- ware-Level QOS expressions shown in table 3. Session 
C is specified as temporal resolution is more important than spatial one. 

In our platform, qtfp performer hardly consumes processor cycle, and mmpx 
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Table 2 Session Specification: User-Level QOS Expression 





Temporal Res. 


Spatial Res. 


Session A 


Any 


Max 


Session B 


Max 


Any 


Session C 


Medium 


Medium 



Table 3 Session Specification: Middle- ware-Level QOS Expression 





Frame Rate 


Image Size 


Session A 


1,2,3,5,6,10,15,30 


320x240 


Session B 


30 


1 60x1 20 , magnified ,320x240 


Session C 


15,30 


magnified ,320x240 



performer consumes 1,666 micro seconds per 160x120 image drawing. Other 
processing like IPC overhead in the conductor costs 638 micro seconds per 
frame. We limit the maximum storage bandwidth of qtfp by 2,500KB/s. 

In our conductor setting, only the top-most session belongs to the individual- 
first group. Maximum QOS of both Session A, B and C consumes processor 
cycle 21.9% and storage bandwidth 2,250KB/s. Both resources are affordable 
for a single session. If we request to create and start session A, B and then 
C, A starts with the maximum QOS. When B starts, since B is the more 
important than A and storage bandwidth is not enough, so A must cut its 
frame rate to 3 fps. When C starts, the max QOS of C forces to give up to 
last B but A remains at 3 fps quality. 

If we eliminate the individual-first group, nothing changes before C starts. 
When C starts, if C ran at the maximum, B must quit to make C run. There- 
fore, C cut its frame rate to 15 fps, and B could continue to run by shrinking 
storage bandwidth to 562.5KB/s, and A could run at 10 fps. 

Mmpx can magnify the 160x120 image to 320x240 by coping, but this con- 
sumes processor cycle heavily. In our system this software magnification costs 
26 milliseconds per a frame. Therefore, the conductor could not utilize this 
for B in the all welfare-most situation. 

Although it is desirable to have a choice of software image magnification, for 
our resource re-distribution algorithm, such a choice that upgrades processor 
resource but degrades storage bandwidth violates our constraint. 
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Table 4 Session Specification: System- Level Expression 





Processor Cyc. 


Storage Bandwidth 


Frame Rate 


320x240 


160x120 


320x240 


160x120 


30 fps 


21.9% 


6.9% 


2,250KB/s 


562.5KB/S 


15 fps 


11.0% 


3.5% 


l,125KB/s 


281.25KB/S 


10 fps 


7.3% 


2.3% 


750KB/S 


187.5KB/S 


6 fps 


4.4% 


1.4% 


450KB/S 


112.5KB/S 


5 fps 


3.7% 


1.2% 


375KB/S 


93.75KB/S 


3 fps 


2.2% 


0.7% 


225KB/S 


56.25KB/S 


2 fps 


1.5% 


0.5% 


150KB/S 


37.5KB/S 


1 fps 


0.7% 


0.2% 


75KB/S 


18.75KB/S 



7 CONCLUSION 

For multimedia session coordination it is indispensable to admission control 
based on quantitative resource management. This assumes that each compo- 
nent of the system must be conscious to its quantitative service cost. Besides, 
resource reservation and/or enforcement mechanism are also necessary. Our 
investigation aims such a predictable environment in order to rigidly coordi- 
nate multimedia sessions. We introduced (i)a QOS translation mechanism and 
(ii)a simplified session coordination algorithm which enable to re-distribute 
system resources among sessions for more stable and predictable session co- 
ordination. This paper gave an experiment on the QOS translation using our 
middleware named Conductor/ Performer system and presented an rigid co- 
ordination for multiple-graded movie playing sessions. 
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Abstract 

Distributed multimedia (MM) systems have to provide users with the ability 
to specify their performance requirements. Quality of service (QoS) parame- 
ters represent an adequate measure for the specification of time-dependent 
MM-data like audio or video streams. In order to guarantee the fulfillment of 
application requirements, a mapping onto the involved network and operat- 
ing system resources has to be performed. This paper shows how QoS trans- 
lation can be performed in distributed MM-sy stems. Parameter translations 
between abstraction layers including a terminology and the interdependencies 
between the parameters are presented. Furthermore, mapping stimuli that im- 
ply a modification of QoS parameters are identified and their respective effects 
are described. 



Keywords 

QoS mapping, QoS translation, QoS parameters, QoS mapping stimuli 
1 INTRODUCTION 

MM-applications are characterized by the capability of handling time- 
dependent data like video streams and time-independent data like traditional 
text. Streams consist of consecutive data units and the presentation of the 
stream must maintain the temporal relations between the consecutive units. 

The qualitative and quantitative properties and requirements of MM-data 
can be expressed by means of QoS parameters. Imagine an application like 
a video conference. Users are geographically separated, but can audibly and 
visually communicate via their MM- workstations, which are interconnected 
by some sort of network. Before data can be sent over the network, it has to 
undergo various procedures like compression, segmentation, etc. These proce- 
dures consume a given QoS budget as they, for example, induce additional 
delay. Since the effects implied by the procedures have to be captured by the 
mapping algorithm, the respective procedures will be referred to as mapping 
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stimuli. All mapping stimuli have to be taken into account in order to guar- 
antee a demanded QoS profile. 

State of the art 

[Ferrari, 1990] has presented translations of QoS parameters like delay, jitter, 
and reliability referring to constant size messages. Furthermore, he proposed 
translations for statistical bounds and fragmentation. [Moran et a/., 1992] in- 
vestigated buffer dimensioning required for jitter smoothing. Throughput 
calculation is performed as a function of SDU size and time and includes 
variable bit-rate (VBR) effects. [Jung, 1996] contributed translations onto 
ATM network Network Performance parameters and additional knowledge on 
the mapping of reliability, when relations between the parameters are not 
one-to-one. [Damaskos et al.^ 1994] translated SDU size, SDU inter-request 
interval, and SDU transmission delay onto ATM performance parameters. 
[Nahrstedt et a/., 1995] translated QoS parameters size, rate, delay, and loss 
rate from media quality to connection quality for constant size media samples. 

The above mentioned approaches provide partial solutions to the mapping 
problem and concentrate mainly on the lower abstraction layers. 

Although future multimedia applications are most likely to operate on data 
that entails VBR traffic, translations of QoS parameters for VBR services have 
hardly been addressed but rather been limited to constant bit-rate (CBR) 
services. 

It is the main goal of this document to discuss stimuli for QoS-parameter 
modifications when mapping is performed across layers and to provide guide- 
lines as to how QoS-parameters are affected by which stimulus. We provide a 
unifying approach that generalizes the mapping process, so it can be applied to 
every abstraction layer. This comprehensive study includes the dependencies 
and corresponding trade-offs between the QoS parameters. 

In Sec. 2 we briefly summarize basic definitions of QoS parameters. Sec. 3 
shows how mapping is performed across the abstraction layer hierarchy. Im- 
portant mapping stimuli are identified that have an, usually adverse, effect 
on QoS parameters. A mapping function is defined that captures the implied 
effects accurately. Conclusions are given in Sec. 4. 



2 QOS PARAMETERS 

QoS mapping is regarded as the process of translating QoS-parameter bounds 
from layer to layer and, finally, to resources, e.g., buffers. In this section we 
will briefly present the definitions of the QoS-parameters that are subject of 
translation, a more thorough discussion is given by [De Meer et al.^ 1997]. 



2.1 Delay 

According to the ISO/OSI Reference Model, the delay of an SDU is defined as 
the time interval between the occurrence of a data.request at a layer’s service 
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access point (SAP) at the sender and the occurrence of the corresponding 
data.indication at the peer SAP at the receiver [Danthine et a/., 1992]. It is 
assumed that data.request and data.indication occur instantaneously. 

The required performance is characterized by the maximum delay Dmax 
that should not be exceeded by the delay D{ of all SDUs i of a given set (or 
stream) on a given layer [Ferrari, 1990]: 

Di<Dmax. Vi. (1) 



2.2 Jitter 

The many existing definitions of jitter which are compared in more detail by 
[De Meer et al.j 1997], have in common to use jitter as a measure for tem- 
poral fluctuations of SDU delays. In this paper jitter is defined according to 
[Moran et aL, 1992]. Given the delay Di of the ith SDU, the jitter J,- of that 
SDU is calculated by subtracting D{ from the maximum delay bound Dmax 
that has been negotiated on: 

t7i = Dmax *“ D%. (2) 

according to [Ferrari, 1990]: The bound for jitter can be given analogously 
to Eq. 1. With the chosen jitter Definition (2), Jmax automatically implies 
the existence of a minimum delay bound Dmin , since J,* can only be at its 
maximum when Di is at its minimum: 

Dmin ” Dmax Jmax’ (3) 

Deterministic jitter 

Typically, networks dynamically impose delays on SDUs, which are not known 
in advance since they depend on load variations and queuing effects in interme- 
diate nodes. In contrast, some procedures impose certain additional variable 
delays resulting in jitter effects, which can be accurately quantified from the 
beginning. To capture these effects, we would like to introduce the notion of 
deterministic jitter. 

Given bandwidth W [^] and the size Si [bits] of the ith video-frame, its 
transmission time U is computed by: t,* = ^. If the maximum size Smax of all 
video-frames is known we can compute the jitter j[trans)i for the ith frame 
induced by the transmission. j{irans)i is the difference between the maximum 
transmission time tmax of the biggest frame and f,-. 



2.3 Reliability 

From a user point of view, reliability is a term which covers all kind of undesired 
effects. In a video conference reliability could express the probability, or some 
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bound hereof, that gaps in audio streams or distorted video frames do not 
occur. Effects related to excess data are not considered in this paper. 

The required reliability can be expressed by the minimum probability Pmin 
of a correct delivery of an SDU, i.e, neither loss nor bit error (s) do occur: 

Fro6(correct delivery) > Pmin- (4) 

Sometimes it is more convenient to introduce an upper bound Emax for the 
probability of an erroneous data delivery: 






( 5 ) 



2A Throughput 

When negotiating throughput, layer N and layer AT — 1 agree on the (max- 
imum) size of an SDU and on the minimum time that must pass between 
SDU-requests at layer TV — 1. Therefore, throughput is defined via SDU size 
5, and the inter-request time T of the SDUs. 

Bandwidth is defined as the number of SDU requests a service providing 
layer is able to accept with a negotiated SDU size in a given interval. The 
requested throughput of a service using layer is defined as the number of SDU 
requests with a negotiated SDU size in a given time interval. 

CBR services usually imply constant SDU time intervals and sizes. In case 
of VBR services maximum and minimum sizes of SDUs are important for 
mapping purposes and should therefore be part of the negotiation. 

More details of the different throughput parameter definitions are presented 
by [De Meer et al., 1997]. 



3 THE MAPPING OF QOS-PARAMETERS 

The mapping of QoS-parameters covered in this paper is limited to quantitative 
translation of the bounds of the QoS parameters. However, some parameters 
will have to be qualitatively translated across abstraction layers. An example 
for this more qualitative translation is given in Sec. 3.1 (c). 



3.1 Prerequisites 

The mappings are performed “top-down” from layer TV -|- 1 to layer TV. The 
reverse translations can in many cases be easily calculated. Ambiguities may 
occur when interlayer relations between QoS-parameters are not one-to-one. 

(a) Notational Remarks 

During the mapping of QoS-parameter bounds, we will stick to the following 
notation in order to avoid confusion with the different bounds involved. 
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On each layer iV, the QoS-parameter bound which is demanded from 

the service providing layer iV — 1, is calculated from the QoS-parameter bound 
. It is known how layer N affects the QoS-parameter bound . The 
QoS parameter budget spent or earned on layer N is accounted for through 
a pessimistic local bound . Correspondingly, the bound that was originally 
demanded by the user, will be called the global bound. 

To refer to delay d or to jitter j, which is caused as a side-effect by some 
procedure X, we use notation d(X) or j(X), correspondingly. 

(b) Statistical Bounds 

The translation of statistical bounds is omitted due to space limitations and 
can be found in detail in [Ferrari, 1990]. 

(c) Reliability 

Assume layer N represents reliability with a single parameter (the upper bound 
of probability for an erroneous delivery). If the probability of an erro- 
neous delivery is represented by two bounds at layer iV — 1, a loss ratio bound 
L^ax SDU error ratio bound qualitatively and 

quantitatively translated. 

Depending on how a lost {N — 1)-SDU affects the reliability of layer N, 
different translations are needed. If a lost {N — 1)-SDU has the same adverse 
effect on QoS as an (iNT — 1)-SDU with single or multiple bit errors, i.e., they 
are both considered useless, then the following mapping can be applied: 

ipN rN—l I tjN—1 

^max ^max ^max * V^/ 

Consider a given bit error ratio on layer N — \ (for the sake of simplicity, 

bit errors are assumed to occur independently) and M as the number of bits in 
an (iV— 1)-SDU. An SDU loss may be indicated by layer N—1 and compensated 
for through layer N by means of dummy SDUs that are used to maintain bit 
count integrity [Jung, 1996]. An {N — 1)-SDU loss is thus considered as severe 
as K bit errors {I < K < M). Under these assumptions the following mapping 
can be applied: 

= (7) 

( 8 ) 



3.2 QoS Mapping Stimuli 

(a) Segmentation and Reassembly 

Video frames can be very large in size such that a network SDU can not 
accommodate a complete frame. Therefor frames have to be segmented at the 
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sending side. At the receiving side the reverse function is performed and frames 
are reconstructed. 

The number M of (AT — l)-SDUs that are needed to transport constant sized 
(TV)-SDUs can be calculated from the size of the (iV)-SDU and the size 
5^-1 of the (iV-l)-SDU: 




In the case of variable sized (iV)-SDUs M is calculated with the maximum 
(i\T)-SDU size S^^^ax instead of 5^. The effects of segmentation and reassembly 
are considered together and the procedure is hereafter referred to merely as 
segmentation. 

Delay 

The fundamental effect of segmentation on delay has been discussed by 
[Ferrari, 1990]. The time d{S/R)max it takes to hand over all of the segments 
to layer — 1 , has to be deducted from the delay bound The time 

d{S/R)max is determined by the number of segments M and the time 
that must pass before layer N — 1 accepts the next {N — 1)-SDU- request. The 
“inter-request” -time has to be negotiated with the underlying layer such that 
Dmax can be fulfilled. 

~ X (M - 1) . (10) 

d(S/R)maT 

Formula (10) provides an intermediate step to proceed with translation to the 
next layer, {N — 1), which is then only aware of the timely delivery of the 
segments, i.e., the {N — l)-SDUs. 

Jitter 

Segmentation induces constant delay so that no jitter results, J^ax = ^maxi 
as long as the product x (M — 1) remains constant. As assumed, 

is constant in all cases. 

In the context of variable sized (iV)-SDUs M, and consequently the de- 
lays induced by segmentation, will differ. The maximum (deterministic) jitter 
j{S/R)max introduced by the segmentation can be determined with the knowl- 
edge of the maximum and minimum negotiated size of (AT)-SDUs, S^^x 

oN . 

*^min * 

= jLr - X i\§^] - f^]) • (11) 

" V ' 

j (S/ It)max 



Throughput 

Segmentation may result in unused space in (N — l)-SDUs. With fixed size 
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(N — l)-SDUs and (iV)-SDU sizes not being a multiple of {N — 1)-SDU sizes, 
segmentation will result in M — 1 full (N — l)-SDUs and one (N — 1)-SDU 
that is only partly filled. 

Although a higher bandwidth is requested from layer A — 1 by x 
layer N will only request a number of bits per second given by ^ x 5^“^. 

Reliability 

Segmentation of SDUs entails appropriate adaptation of reliability require- 
ments. When layer N breaks down (iV)-SDUs into M {N — l)-SDUs then 
the reliability bound demanded from layer N-1 depends on the reliabil- 

ity bound E^ax demanded from layer N. The question is, how an erroneous 
(N — 1)-SDU affects the (iV)-SDU. The translation according to Eq. (12) as- 
sumes that an (AT)-SDU is only correct if all of its parts (i.e., (AT — l)-SDUs) are 
correct. {N — 1)-SDU errors are assumed to occur independently [Jung, 1996]: 

( 12 ) 

“ (13) 

This represents a pessimistic approach, because it is assumed that a single 
erroneous part may corrupt the whole entity. 

The translation of reliability by [Nahrstedt et al.y 1995] is based on a layer’s 
SDU-loss-rate Lr. Although the rate itself being unaffected, the requested 
reliability is increased since there are M times more {N — l)-SDUs than {N)- 
SDUs: 

=Lr^. (14) 

(b) Blocking 

The procedure of mapping several (AT)-SDUs into a single (AT— 1)-SDU is called 
blocking (or concatenation). This implies additional waiting delays. Assuming 
an ATM-network is used, several 16 bit samples of an audio stream have to be 
collected in order to fill a single cell. 

The proposed translations are applicable if two conditions are satisfied: The 
sizes of the (AT)>SDUs are constant and the (AT)-SDU requests arrive at layer 
N according to the inter-request time . The effects of blocking are compa- 
rable to those of segmentation with opposite implications. M (AT)-SDUs are 
concatenated to form a single (N — 1)-SDU: 




Delay 

When blocking is used, delay occurs due to waiting for data from the above 
layer at the sender. The inter-request time is specified by the upper layer 
AT -f 1. Each first (AT)-SDU starting a new block experiences the most delay 
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d[B)max since it has to wait for the following M-1 (AT)-SDUs to fill the (A/^ — 1)- 
SDU: 



D: 



N-i _ 



DZa.-T^ 



d(B)„ 



( 16 ) 



Jitter 

The maximum amount of (deterministic) jitter j(B)max induced by blocking 
is equal to the maximum delay d{B)max- Each first (AT)-SDU, which initiates 
a new block, has to be delayed for d(B)max until the last (AT)-SDU completes 
the block. The minimum delay d(B)min for an (N)-SDIJ is zero since this last 
(AT)-SDU experiences not delay: 

m max = d{B) 

max d{^B)min — d{^B) max • ( 17 ) 

Throughput 

Blocking may result in unused space when the (iV)-SDUs do not neatly fit in 
the (AT — 1)-SDU. The required bandwidth has to be increased, which has been 
done by the calculation of M. The inter-request time of [N — l)-SDUs 

is given by: 

T^“i=T^xM. ( 18 ) 

Reliability 

After the (AT)-SDUs have been assembled into an [N — 1)-SDU bursty errors 
may occur. When one (AT — 1)-SDU is lost, M consecutive (AT)-SDUs are lost. 

If the user is resilient to particular errors, the reliability measures can be 
passed through the layer, since the probability for an erroneous SDU remains 
unchanged: 

^ma"x = EZa.- (19) 

(c) Interleaving 

Interleaving is a measure to increase reliability and is often used in combi- 
nation with forward error correction (FEC) mechanisms. Interleaving can be 
performed with a matrix which is column-wise filled with (iV)-SDUs. When 
the matrix is full, each row is sent as a single {N — 1)-SDU to the receiver, 
who, in turn, waits for all matrix-SDUs to reconstruct the original (AT)-SDUs. 

The translations for reliability are not presented as they are highly depen- 
dent on the error profile of the underlying layer and on the amount of FEC 
information used* . 



Reliability is traded off against additional bandwidth requirements. 
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Interleaving causes additional delay and jitter similar to that introduced 
by blocking if all conditions, as mentioned in Sec. 3.2 (b), are satisfied. 

Throughput is not altered by interleaving but by FEC. The translations 
for FEC are similarly performed as those for overhead (see Sec. 3.2 (e)). 

(d) Playout Buffer 

Statistical jitter can be compensated for by a playout buffer, which only works 
for SDUs that are requested periodically within a period T. Loss is not con- 
sidered here. It is assumed that the clock of sender and receiver proceed at the 
same rate. The removed jitter is traded-off for additional delay due to buffering 
effects. 

For example, if 2 msec of jitter shall be compensated for, the first SDU 
is delayed for the maximum playout buffer delay d{PB)max = 2 msec. After 
this time, after each time interval T an SDU is removed from the buffer. If 
the buffer is empty the next SDU will be passed directly through the buffer. 
Should an SDU arrive at a full buffer, the next scheduled SDU is immediately 
forced out of the buffer. 

Layer N-1 can be conceded an increased jitter bound but has to enforce a 
stricter (reduced) delay bound: 

( 20 ) 

= JL. + d{PBUa.. ( 21 ) 

The size 5 b of the playout buffer depends on the size 5 of the SDUs, the 
jitter J that shall be compensated, and the inter-request time T of the SDUs 
[Moran et al.^ 1992]. When SDU sizes vary, the maximum SDU-size Smax has 
to be taken into account instead of 5: 

5B = f^]*5. (22) 

The drawback of using a playout buffer is that additional delay might be 
imposed. Most important, though, is the handling of the first SDU. The first 
SDU should be delayed by d{PB)max only if it had suffered the minimum 
delay. In case the first SDU suffered maximum delay playout could commence 
at once. As we do not have information about the delay of the first SDU we 
always have to delay it by d{PB)max- 

In case of deterministic jitter, the delay of the first SDU is known. Conse- 
quently, deterministic jitter can be removed with less effort than stochastic 
jitter. * 

For the removal of deterministic jitter induced by blocking, for example, 
the following measure is taken: Each SDUs is delayed by the amount of a 



•Every SDU is then delayed by Dmas] so the particular SDU suffers more delay but the 
delay bounds remain unchanged. 
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jitter compensation delay d(JC'),*, which depends on the delay d{B)i that was 
imposed on the ith SDU due to blocking, and the maximum delay d{B)maxy 
which any SDU experiences due to blocking: 

d{JC)i = diB)ma.-d{B)i. ( 23 ) 

Throughput and reliability requirements remain unchanged by the playout 
buffer if buffer overflow does not result in SDU-loss. 

(e) Overhead 

Overhead can be due to operating systems functionalities, like scheduling, or 
due communication protocol data. 

Delay 

It is assumed that at is known at every layer N how much time is needed for 
these tasks and this portion should be deducted from the given delay bound 

DN 
^max * 

Throughput translation is necessary on each layer N, when overhead (pro- 
tocol data) is attached to (iV')-SDUs. The SDU-size 5^“^, which is demanded 
from the underlying layer AT — 1, is adjusted by adding the number of over- 
head bits to the size of the (TV)-SDU. The translation for reliability 
depends on how sensitive the protocol data is compared to the (A^)-SDU. The 
reliability measures at layer N — \ are chosen according to whatever being 
more demanding, overhead or (AT)-SDUs. 

(f) Coding 

Coding can have spatial and temporal implications. In an MPEG coded video 
sequence, for example, each frame is coded according to one of three encod- 
ing modes: I, P, and B. While the I-frames (intra-coded) are coded without 
references to any other frame, P-frames (predictive) are coded as difference 
pictures from the last I- or P-frame. B-frames (bi-directional predictive) are 
coded as differences from an interpolation of the preceding and the succeeding 
I- or P-frame. So when a B-frame has to be coded, future I- or P-frames have 
to be waited for. 

The maximum coding delay for MPEG d{MPEG)max depends on the max- 
imum computing time d{C)max for encoding a bidirectional frame, on the 
maximum distance R of a. B-frame to the following reference frame, and on 
the frame rate / at which the frames are generated (this is similar to blocking 
and peak smoothing, since it has to be waited for future data): 

d(MPEG)max = RXj + d(C)mar. ( 24 ) 

The minimum delay for an MPEG-coded video frame is equal to the delay 
of the fastest P-frame (en/de-coding), which does not have to wait for future 
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reference frames: 



d{MPEG)min--d{C)min^ (25) 

The jitter caused by MPEG coding is once again calculated by subtracting 
the minimum from the maximum delay. 

The reductions in average bandwidth requirements depend on the content of 
the video and the IPB pattern. The required bandwidth is reduced at the cost 
of additional delay and jitter. Moreover, reliability has to be increased since 
the MPEG-coded video is more sensitive to errors than the original frames. 



(g) Compression 

Compressing SDUs is a measure to reduce the size of SDUs. The translation 
of the delay and jitter parameter bounds are simple. The new bounds are 
computed by deducting the maximum delay /jitter that can occur during com- 
pression tasks from the given delay and jitter parameter bounds. 

Throughput 

If there is no guaranteed compression minimum that holds for all SDUs, the 
reduction of some of the SDUs cannot be used for a deterministic bandwidth 
requirement. With the minimum compression ratio Cmin from Eq. 26 the [N — 
l)-SDU-size is given by Eq. 27 : 



Cmin = rnax 



( 



size after compression 
size before compression 



) 



,VSDUs, 



(26) 






= X c„ 



(27) 



It has to be noted that compression increases the vulnerability to distortions 
of the SDUs. So reliability requirements might need adjustments. 



(h) Peak Smoothing 

VBR services can have large bandwidth requirements Wmax which can be re- 
duced by utilizing peak smoothing. When peak smoothing, also known as 
frame spreading (cf. [Ismail et a/., 1995]), is used, an (iV)-SDU, e.g., each 
video-frame, is not transferred completely in its request period but in 
multiple periods. 

Depending on the burstiness of the SDU-size and on the budget of time for 
smoothing, the maximum SDU size for layer N-1 can be reduced to a 

value close to the average SDU-size Savg- 

The inter-request time of the SDUs remains unchanged by peak smoothing 






The peak smoothing delay is easy to calculate, since it has similar effects 
as blocking. The time interval of interest is given by the inter-request time 
of the (iV)-SDUs. The formula is the same as for blocking (Sec. b). Under our 
assumptions peak smoothing has no effect on jitter. 
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4 CONCLUSIONS 

An overview was given how the translation of QoS parameters across layers 
may be performed. We identified some of the important features of a distrib- 
uted multimedia system which stimulate effects of typical mapping issues on 
QoS parameters. Existing partial solutions of the mapping problem were re- 
lated to each other. Additional mappings were given in order to complement 
the existing approaches from the literature for a more comprehensive view. In 
particular, effects related to VBR services were high-lightened and extended 
approaches were derived. Further research is necessary in order to relate the 
mapping issues closer to the cognitive capabilities of the human user. 
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Abstract 

In this paper we present an integrated view of translation and admission con- 
trol relations for MPEG video streams between a multimedia distributed ap- 
plication such as video-on-demand, and its underlying system resource, CPU. 
Both services are presented as core services of our Quality of Service (QoS) 
communication model. This communication model is analyzed for different 
MPEG grouping schemes and communication paradigms. We show under 
these schemes and paradigms the translation and admission control impli- 
cations for deterministic QoS specification which must be considered in any 
MPEG-based multimedia system. 

Keywords 

QoS translation. Admission Control, MPEG video, Quality of service 

1 INTRODUCTION 

Communication model for quality-of-service(QoS) guarantees has been pro- 
posed to ensure the guaranteed service video servers and clients need [2]. 
The service user sends the QoS specification to the service provider. The 
service provider translates the overall, higher-level QoS specification require- 
ments into requirements for individual resources which the service provider 
needs for service provisions. Once the QoS specification has the corresponding 
QoS/resource domain representation (e.g. CPU resource domain), the resource 
broker in the service provider can perform admission control. The admission 
control either admits the resource amount needed for the corresponding QoS 
requirement, or rejects the resource amount, or suggests new resource amount, 
which results in new QoS. 

This paper presents detailed analysis of the communication model for QoS 
guarantees if the service user is a MPEG video application and the service 
provider is the underlying system layer resource, specially processor. 

According to the communication model, we consider application QoS tai- 
lored toward MPEG video and corresponding system QoS parameters. We 
summarize all considered QoS parameters with their notations in Table 1. 

2 QOS TRANSLATION AND ADMISSION CONTROL FOR CPU 
Admission control performs schedulability tests to decide if real time schedul- 
ing can be achieved. With respect to schedulability of periodic jobs, Liu and 
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QoS type 


QoS parameter 


Symbol 


Comment 


Application 


Sample size 
Sample size (I, P, B) 


Ma 

M'a, mJ, Mf 




QoS 


Sample rate 


Ra 






Sample rate (I, P, B) 


d/ dP nB 


R\ ={Gk/G) RA, k = I,P,B 




Number of frames per GOP 
Compression pattern 


G 

Gj, Gpf Gb 


G = Gi + Gp + Gb 




Original size of GOP 


Mg 






Processing size of GOP 
Degradation factor 


M'g 

D 


D=(M'aiMG) 


System 


Computation time 


G (Cf,Cg,Gm) 




QoS 


Cycle time 


T{Tf,Tg) 





Table 1 QoS specification 




Figure 1 Frame-based scheme and GOP-based scheme 

Layland [1] suggested rate monotonic(RM) scheduling and earliest deadline 
first (EDF) scheduling based on specific assumptions. Both of them require as 
parameters computation time{C) and cycle time{T) for their schedulability 
test. 

Frame-based scheme In frame-based scheme, the processor allocates schedul- 
ing time to process and transmit each frame. In terms of scheduling, RM and 
EDF have the assumption that execution times need to be constant for all 
periodic jobs. In order to fulfill this assumption, maximal computation time 
for all processing units is allocated to process each unit. The maximal compu- 
tation time is the time required to process maximal size of I frame in MPEG 
video as shown in Figure la, so the computation time is as follows. 

Cf = max{Eval{Mj^),Eval{M^),Eval{M^)) = Eval(Mj^) (1) 

where Eval(Mj^) > Eval(M^) » Eval(M^), Eval is the function to mea- 
sure the computation time of a given size of MPEG frame(s). Also, since 
sample rate Ra is known for the MPEG video characteristics (application 
QoS), the cycle time T can be computed osTp ^ 

The frame-based scheme is adequate to apply to a MPEG compressed video 
which has relatively small range of variation in any frame size. This is the case 
if MPEG stream consists of only consecutive I frames, not including P and B 
frames. 

This scheme has notable drawbacks for scheduling of communication tasks 
if MPEG video has compression pattern including P and B frames. The rea- 
son is that the processor is underutilized because P and B frames use up only 
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a portion of allocated schedule time. Also, since each frame is individually 
packetized, processed, and transmitted, these steps cause increased overheads 
in proportion to the number of frames. The extra time for context switching 
is the typical overhead belonging to this case. 

GOP-based scheme A GOP includes at least one I frame to be a reference 
frame along with P and B frames. Each GOP is independent of the other 
GOP’s, since all the frames in a GOP can be decoded without referring to 
other GOP's. In this respect, a GOP can be a processing unit of MPEG video 
data. Using definition in QoS specification, the computation time needed to 
process a GOP is 

Cg = EvaliMo) = Gi ■ EvaliM^) + Gp • Eval{M^) + Gp ■ Eval(M^) (2) 
and the cycle time to process a GOP corresponds toTo = Here we find 
the fact that computation time for all frames in a GOP has larger value in 
frame-based scheme than in GOP-based scheme, since 

Cg < {Gi +Gp + Gp) ■ Eval(M^) = G Cp (3) 

The above computation and cycle time is in the case that all the frames 
in a GOP are processed and sent to clients. On occasion, such a full service 
cannot or does not need to be provided. For example, when the server does not 
have enough scheduling time to support full service, it could suggest degraded 
service to a client by sending a part of GOP. Also the server does not need to 
send full video frames if client does not want to get full delivery service. All 
these range of services can be represented using degradation factor, D = 

of which value ranges [^, ^(= 1)], since Mq could take its value as one I 
frame as the lowest bound, or all frames in GOP as the upper bound. Once 
we define J5, the computation time is 

Cg = EvaliM'o) = EvaliMo • D) (4) 

Figure lb illustrates a full service in which the server processes a whole GOP 
that comprises I, P, and two B frames. As a degraded service, one of B frames 
is dropped out, so it is not processed or transmitted in Figure Ic. In this case 
D is smaller than 1, because Mq corresponds to time needed to compute a 
GOP excluding a B frame. 

This scheme has advantages over frame-based scheme for communication 
tasks. First, this scheme results in maximal CPU utilization. Secondly, various 
services can be specified by both server and client using degradation factor. 
Third, this scheme has less overheads for packetizing, processing and trans- 
mitting compared to frame-based scheme. But if the loss of a GOP packet 
occurs in a network, all frames in a GOP are lost. 

Multicasting scheme We now consider a server which receives a number 
of requests for the same video object. There can be two different schemes to 
process these requests on the video server or router: unicasting and multicas- 
ting. Unicasting scheme means that all demands on video data is processed 
separately, even though clients request the same video data simultaneously. 
On the other hand, multicasting scheme deals with simultaneous demands on 
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the same video data as one demands. As a result, there exists only one I/O 
stream from disk to CPU to support those requests. 

We can relax the assumption of simultaneous requests on the same video. 
If we employ the batching technique, a group of demands on the same video 
which arrive within specified duration can be processed at the same manner. 
Let At denote the specified duration, which can be obtained by heuristics. 

Now we present the translation of QoS parameters in the multicasting com- 
pared to unicasting scheme. Let A be the arrival rate of requests, and N be 
a random variable denoting the number of requests. If we assume the ar- 
rival process is Poisson and the system is M/G/1, then the expected number 
of requests is £7[iV] = A • At and, expected latency(L) for a request [3] is 
• Then the computation time of requests within At in uni- 
casting scheme becomes 

Cu='£{E[Li] + Ci) + cs (5) 

t=l 

where cs denotes accumulated context switching time for all requests. When 
using multicasting scheme, the computation time amounts to 
CM = E[Li]-^Ci (6) 

which is the time needed to process only one processing unit. 

3 CONCLUSION 

This paper presented an integrated view of translation between MPEG com- 
pressed streams and underlying resource, CPU; and its admission control 
within the resource management. Both services were presented as core ser- 
vices of communication model. This communication model was analyzed for 
different representation schemes of MPEG video (frame/GOP based) and 
for different communication paradigms (unicast /multicast). We showed under 
these schemes and paradigms translations and admission control implications 
which must be considered in multimedia systems processing and communi- 
cating MPEG video streams. 
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1 INTRODUCTION 

The term QoS has been originally used in the context of network communica- 
tion resources and then in the context of system resources needed for multime- 
dia applications. It now stands for specific resource management as required by 
applications and relating to non-functional execution properties implemented 
by the processing environment (e.g. availability, security, responsiveness). In 
that framework, there exists a wide spectrum of application domains having 
QoS requirements (e.g. multimedia, military, parallel, telecommunication ap- 
plications). In the same way, there is a growing diversity of available software 
platforms implementing system support for guaranteeing a certain QoS (e.g. 
multimedia architectures (Nahrstedt & Smith 1996), standard distributed pro- 
cessing environments (TINA-C 1995)). The goal of our research is to provide a 
development environment that eases the construction of QoS-demanding ap- 
plications through the re-use of existing QoS-related techniques. Our solution 
relies on the description of the application’s software architecture, which in- 
cludes the specification of the execution properties that must be provided by 
the underlying Distributed Processing Environment (DPE). Execution prop- 
erties subdivide into two categories: (») interaction properties that capture the 
communication patterns among the application’s modules and that allow to 
reason about the adequacy of a given communication platform with the com- 
munication protocol required by the running modules, and (it) QoS properties 
that capture the resource management policies implemented transparently by 
the underlying DPE and that enable to reason about the adequacy of the 
DPE with respect to the application QoS requirements. The next section 
outlines description of software architectures together with the specification 
of associated execution properties. Conclusions then address related work and 
our current and future work. 
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2 DESCRIBING QOS-ENABLING SOFTWARE 
ARCHITECTURES 

Our proposal builds on results produced in the software architecture research 
field of software engineering (Perry & Wolf 1992). Ongoing research work aims 
at providing a sound basis for the specification of various styles of software 
architectures. An architectural style identifies the set of patterns that should 
be followed by the system organization, that is, the kinds of components to 
be used and the way they interact. 



2.1 Describing Software Architectures. 

Although the software architecture field is continuously evolving, it is now 
accepted that the description of an architecture decomposes into at least three 
abstractions (e.g. (Shaw, DeLine, Klein, Ross, Young & Zelesnik 1995)): 

1. components that abstractly define computational units written in any pro- 
gramming language; 

2. connectors that abstractly define types of communications (e.g. pipe, RPC) 
between components; 

3. configuration that defines a system structure (i.e. a software architecture) 
in terms of the interconnection of components through connectors. 

Development environments that are based on the software architecture para- 
digm integrate an Architectural Description Language (ADL) that allows 
system specification in terms of the three above abstractions, and runtime li- 
braries that implement base system services (including primitive connectors). 
Such an architectural description fosters software reuse, evolution, analysis 
and management. However, in order to be able to reason about the correct- 
ness of a software architecture firom the standpoint of resource management 
implemented by the underlying DPE, the description of connectors should be 
enriched with the specification of associated execution properties that subdi- 
vide into interaction and QoS properties. 



2.2 Specifying interaction properties. 

Interaction properties relate to the communication patterns that are imple- 
mented by the DPE. Thus, the specification of execution properties allows 
to verify that the use of communication protocols by the application modules 
is correct with respect to the protocols that are implemented by the DPE. 
Formal specification of interaction properties is addressed by the Wright ADL 
introduced in (Allen & Garlan 1994). Using Wright, a component is described 
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as a set of port processes that are the component interaction points, and 
the coordination process defining coordination among ports. The behavior 
of a component is then the parallel composition of port and coordination 
processes. Similarly, a connector is described as a set of role processes that 
implement communications among components, and the coordination process 
that defines the coordination among roles; and the behavior of a connector is 
defined as the parallel composition of role and coordination processes. Finally, 
a configuration is described as a set of components and connectors, which are 
interconnected through appropriate bindings between ports and roles. Given 
the use of CSP-like notations, the correctness of a configuration with respect 
to the communication protocols that are used can be checked through the 
refinement concept. Basically, it must be verified that port processes refine 
the role processes with which they are bound. 



2.3 Specifying QoS properties. 

QoS properties describe abstractly the resource management policies that are 
transparently implemented by the DPE. Hence, the specification of such prop- 
erties allows to verify that the DPE guarantees the application constraints 
relating to various non-functional properties (e.g., availability, responsiveness, 
security, timeliness). The QoS-oriented description of distributed software 
architectures constitutes the basis of the ASTER configuration-based pro- 
gramming environment (Bidan, Issarny, Saridakis & Zarras 1997). Using the 
ASTER environment, it can be checked automatically whether a given dis- 
tributed platform (characterized using connectors) meets the QoS require- 
ments of communicating components with respect to the specified QoS. Such 
a verification is achieved using a logical tool that implements specification 
matching. 

ASTER further supports customization of a platform from the standpoint of 
QoS by selecting within the software repository, the complementary software 
components that are needed to support a given QoS. As mentioned in the 
introduction, there is a wide diversity of execution properties relating to QoS. 
Up to now, we have been mainly concentrating on security and availability 
issues. Prom the standpoint of responsiveness and timeliness, we are looking 
for solutions based on existing work in this area (e.g., (Demeure, Farhat- 
Gissler & Gasperoni 1996, Lakas, Blair & Chetwynd 1996)). 



3 CONCLUSION 

The specification of QoS-enabling software architectures is not a new concern. 
In particular, let us mention the RM-ODP standardization effort (ISO/IEC 
1994) and the Telecommunication-oriented TINA distributed software ar- 
chitecture that is being specified (TINA-C 1995). These proposals prescribe 
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notations for specifying the QoS demanded by applications. However, QoS 
specification is addressed with respect to a specific distributed software ar- 
chitecture. On the other hand, architectural descriptions that have been ad- 
dressed in Section 2 enable to describe different types of QoS-enabling software 
architectures. In addition, let us mention that the ASTER environment allow- 
ing QoS-oriented description of software architectures can be considered as a 
programming environment implementing the TINA’s computing architecture. 

We have been experimenting our approach to deal with QoS properties re- 
lating to general purpose distributed applications and to telecommunication 
applications (Bidan et al. 1997). We are now working on the complete speci- 
fication of timeliness constraints so as to address specification of multimedia- 
dedicated software architectures. In addition, we are working on the specifica- 
tion of interaction properties based on the proposal of (Allen & Garlan 1994) 
so as to reason about the adequacy of a DPE for a given application with 
respect to the complete set of execution properties required by the application. 
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Abstract 

Next-generation slim hosts or terminals (like PDA’s, settop boxes, and net- 
work computers) are expected to support sophisticated continuous media ap- 
plications. Since these terminals have very limited processing power, the appli- 
cation processing delay can be a significant component of the end-to-end QoS. 
We call this delay a terminal QoS measure to distinguish it from end-to-end 
QoS measures like packet loss, delay, and delay jitter. Computing the pro- 
cessing delay can be tricky since many of the continuous media applications 
are smart and can adapt to network conditions. Such applications can use 
RTP/RTCP feedback of end-to-end QoS to continually change their output 
bitrate. Each adaptation is associated with a different amount of processing 
on the terminal. 

In this context, we pose the following problem. Consider a terminal that sup- 
ports multiple concurrent adaptive applications. Each application uses end-to- 
end QoS feedback to adapt itself according to its adaptation algorithm. What 
effect do the adaptations have on the processing demand on the terminal? 
That is, what is the processing delay as a function of the adaptations? In this 
paper, we provide a theoretical framework to understand this interaction. 

Keywords 

QoS Modeling-Analysis-Evaluation, Adaptive Applications, Internet AppU- 
cation Management, QoS Guarantees in Internet, Terminal or Host QoS, 
Continuous-Media Applications. 

1 INTRODUCTION 

There is an intensive research and development effort ongoing in trying to 
make slim hosts like PDA’s, settop boxes, and communicators Internet-aware 
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[1]. Such hosts have limited processing capability but are being used to sup- 
port increasingly sophisticated applications. In the scope of this paper, we call 
such hosts terminals, to distinguish them from the hosts that connote a PC or 
workstation with larger processing capability and memory. The next genera- 
tion terminals are expected to support continuous-media (CM) applications 
such as audio and video streams, along with other traditional applications. 
Currently such CM applications are supported on powerful hosts [2]. Many 
of these applications are implemented and delivered using the RTP transport 
framework [5]. A few [2, 3] have also been improvised to adapt their behavior 
based on the feedback of RTCP messages that convey end-to-end QoS param- 
eters like packet loss, network delay, etc. It is expected that such adaptive CM 
applications will eventually be deployed on terminals. Under such a scenario, 
we conjecture that the processing delay on end terminals could become a sig- 
nificant part of the end-to-end QoS. Processing delay on the terminals is thus 
a QoS measure. We prefer to call it a measure of terminal QoS to distinguish 
it from end-to-end QoS. 

If we analyze recent work on QoS-based issues, it is evident that there are 
two distinct threads, one that focuses on the networking aspects and the other 
on the operating systems (OS) aspects. The philosophy of the first thread is 
to ensure end-to-end QoS in the face of network evils. The basic idea is to 
give applications a controlled share of the network resources so as to safe- 
guard their performance. Typically, QoS is ensured through a combination 
of reservation protocols [4] and transport delivery/adaptation/renegotiation 
mechanisms [5]. For instance, network protocols like RSVP can be used to 
specify and guarantee resources within the network while frameworks like 
RTP/RTCP can be used to regulate the rate of a sending application so as 
to reduce network traffic. The other community focuses on the OS aspects of 
end-systems, and aims to provide processing guarantees to CM applications. 
This is typically done through the use of real-time priority-based schedulers 
and clever resource sharing schemes [6, 7, 8]. 

Given the relatively mature body of work in both these communities, it 
is appropriate to start exploring the interaction between their work. For in- 
stance, in the networking conununity, the design of RTP-based adaptation 
algorithms has thus far been based on end-to-end QoS measures such as loss 
[3, 5, 9]. In such algorithms, when the packet loss increases beyond a threshold, 
the adaptation algorithm shifts to lower adaptation levels. A lower adapta- 
tion level corresponds to a reduced bit-rate and hence lower network traffic. In 
general, changing adaptation levels changes the processing demand on the ter- 
minal, thus changing''' the terminal QoS (quantified by the overall processing 
delay of an application). Thus far, there has been little work in characteriz- 



* Table 1 in [10] presents a good example of how the CPU execution time increases with 
lowered adaptation level in the context of packet audio. LPC encoding (lower adaptation 
level) in an audio application incurs 110 times the execution time as PCM encoding (higher 
adaptation level). 
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ing the impact of adaptations on the total processing delay of an application, 
especially when multiple such applications concurrently share the processor. 

Prom the other end, studies in the multimedia and real-time OS community 
have designed run-time schedulers to support applications with varying load. 
However, specific changes in applications due to adaptations have not been 
studied. Also, we are not aware of any work that analyzes (at compile or 
design time) the impact of adaptive applications on processing. 

In this paper, we wish to address this intersecting hole. Our objective is 
to quantify the impact of multiple adaptive applications on the terminal QoS 
(processing delay) of each application. Refer to Figure 1. This is a hard prob- 
lem since adaptive applications introduce variability in the offered processing. 
Our approach will be abstract simple models (based on a mixture of related 
work in the literature and a good deal of intuition!) for adaptive CM applica- 
tions and for the processing demands on a terminal. Assuming these models, 
we derive exactly the total processing delay distribution of each application 
when multiple adaptive applications concurrently run on the terminal. We 
expect the results obtained in the paper to be used to design adaptation algo- 
rithms, real-time schedulers, and to understand clearly the tradeoff between 
end-to-end QoS and terminal QoS. 




Figure 1 End-to-end QoS and Terminal QoS 



1.1 Methodology 

We now summarize the proposed methodology — details are presented through 
the rest of the paper. The first step is to model the adaptation of each appli- 
cation at the sender and receiver terminals as a time- varying dynamic pro- 
cess. The notion is that each adaptive application is associated with different 
adaptation levels^ where an adaptation level represents a specific bit-rate. This 
bit-rate could correspond to a particular refresh rate [3, 9], or a particular al- 
gorithm [10], or to a particular coded layer [11]. We focus on modeling the 
adaptation of applications based on RTP/RTCP loss feedback. In this case, 
the adaptation process of an application changes its level when the next feed- 
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back report (RTCP sender/receiver report) indicates that the network loss ex- 
ceeds a certain threshold. We model the transitions of this adaptation process 
through time-invariant probabilities. The interval between reports is assumed 
to be uniformly distributed (in accordance with the interval of RTCP reports 
[5], assuming none of them are lost!). In the second step , we model each appli- 
cation as a task graph with several alternative execution paths. Each task can 
have an arbitrarily distributed execution time. A run-time environment acti- 
vates the tasks to be run on the processor based on a priority function; tasks 
are nonpreemptive. We assume that only one of the several execution paths in 
the application task graph is activated at run-time depending on the current 
adaptation level. This provides the link between the adaptation in the applica- 
tion and its computation demand. Unfortunately, this dependence makes the 
analysis of the computation complicated. We invoke a reasonable assumption 
that the task-level changes (rate of milliseconds) are much faster than the 
changes in the adaptation process (rate of seconds or minutes); consequently, 
we can characterize the state of computation on the processor between two 
consecutive changes in the adaptation process. In the third step , we consider 
multiple applications that run concurrently on the terminal. Each application 
is assumed to adapt based on its adaptation process. We show that the pro- 
cessing demand imposed by a particular vector of adaptation levels can be 
analyzed by formulating the computation as a well-defined stochastic process. 
Our main result is that we derive exactly the processing delay distribution in 
terms of the stationary distribution of the jumps made by the computation 
process. 

The rest of the paper is organized as follows. In Section 2, we describe how 
applications are specified. In Section 3, we propose models for the adaptation 
process and for the computation process. In Section 4 we analyze the compu- 
tation process by formulating it as a semi-Markov process, and we compute 
its stationary distribution. In Section 4.2, we derive the processing delay dis- 
tribution. We conclude after outlining possible applications of our analytical 
results. 



2 APPLICATION SPECIFICATION 

We assume that each application is specified by a task graph consisting of 
nodes and arcs as shown in Figure 2a. Nodes represent task-level computa- 
tions and arcs specify precedences between nodes. Each node in the graph 
(other than the source and sink nodes) is assumed to incur an arbitrarily dis- 
tributed execution time on its designated resource. Without loss of generality, 
we assume that the execution time is a discrete random variable [12] that takes 
one of the values ei, C 2 , .., Ck with probabilities pi,P 2 ? -jPib respectively, where 
these probabilities sum to 1. Such a distribution can approximately model 
execution time variations due to data dependencies or due to architectural 
effects like cache misses and I/O contention. 
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Arc (Precedence) 




executicMi time 



Application "A" 

a. Single iteration of the ai^lication 




b. Repetitive behavior of the application is specified by successive 
iterations, separated by a spacer node 



Figure 2 Application Specification and Repetitive Behavior 



An application consists of several alternative execution paths within each 
iteration. Each path is made up of a succession of nodes between the source 
and sink nodes. An execution path is generally assumed to be chain structured. 
When multiple arcs merge into a node, we assume that the node waits for 
execution till it receives data from all its incident arcs that are included in 
the current execution path. 

To model the repetitive behavior of CM applications, we assume that data 
samples arrive at the (infinitely buffered) source node of an application at 
a fixed interarrival frequency dictated by the input rate of the application. 
For instance, in a video application this rate could correspond to the refresh 
rate; if the refresh rate is 30 frames/sec, the interarrival time is 33ms. The 
precise time when these input samples are taken in by the source node for 
processing depends on when the earlier samples have finished processing. If the 
earlier samples are still being processed by the application when the next input 
samples arrive, the input samples are made to wait, otherwise, they are taken 
in for processing immediately. This behavior is modeled in the application 
task graph by the use of an artificial node called the spacer node. Refer to 
Figure 2b. Thus, samples are made to wait if the processing delay of the 
earlier samples is less than the interarrival time between samples; the spacer 
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node releases samples at exactly the interarrival frequency. If, on the other 
hand, the processing delay is more than interarrival interval, the spacer node 
releases samples immediately after the processing is done. In either case, the 
application task graph repeats as soon as the spacer node releases the samples. 
This models the behavior of repetitive continuous media applications. 

As stated before, the current level of the adaptation process of the applica- 
tion determines the execution path to be activated within the current iteration 
of the application. These concepts are now clarified by means of an example. 
Figure 3 shows the select parts of an H.261 video encoder application [13]. 
We indicate only a single iteration of the application for lack of space. Two 
alternative execution paths, each with different time intervals available for 
processing are shown. The two paths correspond to refresh rates of say 15 fps 
and 8 tps. One of the two paths is activated at the beginning of each iteration 
depending on the latest adaptation level. The fork in each execution path 
after the quantizer indicates that data samples traverse both the arcs to the 
VLB and the IQuantizer. 



Execution Path Corresponds to Frame Rate of 1 5 fps (random) 




\ Execution Path Corresponds to Frame Rate of 8 fps 




ME: Motion Estimation & Compensation 



DCT: Discrete Cosine Transfmn 
Quant: Quantizer 
VLE: Variable Length Encoder 
I+I+A: I Quant + 1 DCT + Adder 



Figure 3 Specifying an iteration of the H.261 video encoder application 



Note that an audio encoder could be described similarly. Unlike video 
though, the input rate of audio samples is typically constant. In this case, 
an adaptive audio encoder can have different execution paths represent dif- 
ferent encoding algorithms, not different refresh rates. The adaptation levels 
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and the most recent RTCP feedback can be used to switch between different 
encoding algorithms like PCM, ADPCM, GSM, or their combinations, etc. 

Thus far, we have modeled a single application. To model multiple con- 
current applications, we combine the task graphs of individual applications 
into a single aggregated graph. Since applications can begin at different start- 
ing times, their temporal skew is captured by the addition of a node to each 
application that models the lag of each application. The aggregated graph 
terminates into a final sink node when all the individual applications finish 
their processing at the same exact time. The processing delay is measured 
over the interval of the aggregated graph. 



3 ANALYTICAL MODELS 

In this section, we discuss the analytical models used to describe the adapta- 
tion process of each application and the state of computation in a terminal 
that runs multiple adaptive applications. 

3.1 Adaptation Process 

We consider the particular case when applications adapt based on RTCP-like 
feedback of network congestion parameters such as packet loss or delay. This 
feedback occurs through sender (or receiver) reports. We assume that the 
inter-report time T^^port ^ adaptive application is uniformly distributed 

between minimum and maximum limits of treport.mm *report,max respec- 
tively [5]. Once a report is received, the current adaptation level is either 
retained or changed depending on the end-to-end QoS feedback. We model 
the adaptation level changes at the receipt of each report as Markovian jump 
process with level-dependent transitions. Thus we approximate the possibility 
of different QoS reports in a level by difierent probabilities. Refer to Figure 4. 
The transitions between adaptation levels m and n are assumed to occur with 
a probability Vmn- This probability can be determined by profiling the adap- 
tation of an actual application under an adaptation algorithm. ([3] represents 
an example, where the adaptation is based on an algorithm that imposes an 
additive increase, a multiplicative decrease, with a small dead-zone to deduce 
the maximum output rate of a sender.) Note that these transition probabili- 
ties are time-homogeneous; this may not be a valid approximation in pr 2 w:tice, 
but as a starting point, we believe it is reasonable. 

Assiuning each application adapts based on its reported end-to-end QoS, 
independent of other applications, we can construct similar models for all 
the concurrent applications being supported on a terminal. If M/ represents 
the adaptation level of application i at instant t, the joint process M = 
represents the joint adaptation level of all the applica- 
tions currently nmning on the terminal. 
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Adaptation Level 




*U(t 

report,min report,max ^ 



Figure 4 Modeling the adaptation process of application 1 



3.2 Computation Process 

In this section, we are interested in characterizing the processing load that 
is offered to the terminal by multiple adaptive applications. We make the 
following assumptions regarding the run-time environment in the terminal: 

(1) Mapping of tasks to the processor is done at compile time and is known. 

(2) Tasks are non-preemptive. (3) A simple run-time scheduler allocates one 
of the possibly many waiting tasks to a ready processor based on a known 
priority function. (4) Communication costs are ignored, as are effects of limited 
memory. 

As discussed before, changes in the adaptation level of each application 
trigger changes in the execution path of the application. Naturally, the pro- 
cessing load change when the adaptation level changes. It is extremely hard 
to analyze changes in the processing load coupled with the changes in the 
adaptation level. Fortunately, we can use the property that changes in the 
adaptation level are on a much larger time-scale than the changes in the pro- 
cessing due to different tasks. Under the circumstances, we can assume that 
the aggregate processing load on the terminal reaches steady-state between 
the consecutive changes in the joint adaptation process. As we shall see, this 
simplifies the analysis considerably, and allows us to decouple the dynamics 
of the processing load from the dynamics of the adaptation process. 

We now represent the state of computation in the terminal through a state 
process. The key observation is that we can model the state process as a semi- 
Markov stochastic process. Such a process has only one-step memory and the 
stationary probability distribution of its jumps to a particular state can be 
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exactly computed. This in turn enables us to compute the processing delay of 
an application. In Section 4.2, we derive the processing delay distribution. 

We define next a few variables that characterize the state of computation 
as a function of time. Let the transition sequence A = {Anyfi = 0,1,..} be 

the time-instants when the state of the computation changes. Aq = 0. We 
define a vector sequence Y = {Fn,n = 0, 1, ..}, where Yn = = (set of 

nodes ready and waiting at transition time A" , the delay incurred by these 
nodes thus far), where A^ denotes the time just prior to the nth transition 
time. Next, we define the sequence Z = {Zn,n = 0, 1, ..}, where Zn = {J,rj) 
= (set of nodes running at transition time An, remaining execution time of 
these nodes). Sequences Y and Z capture information about running and 
waiting nodes. We also define a sequence U that stores, at discrete points 
in time, information about how long an application path has been running. 
That is, U = {Un,n = 0, 1, ..}, where Un = {App,m ^^^ = (application, 
adaptation level of application at instant ^4”, elapsed time of application at 
time A“). Here, is set to zero at the start of each application iteration, 
and is incremented at transitions when nodes in that iteration finish running 
or finish waiting. Figure 5 illustrates the state process for a simple example 
with two applications. 

Observation The joint sequence {Y, Z, U) represents the state of computation 
at each transition and is a Markov chain. By joining the state of computation 
between transitions by straight lines, we obtain the state process X. X is 
a continuous-time stochastic process and since its underlying jump process 
(y, Z, U) is Markovian, it is a semi-Markov process* [14]. We omit the proof 
for brevity. □ 



4 COMPUTING TERMINAL QOS 

In this section, we derive the terminal QoS measures based on the framework 
developed thus far. In the first subsection, we compute, for a given vector M of 
adaptation levels, the stationary distribution tt^ of the sequence {Y,ZyU), 
where (i,j,a) represents a state visited by (Y,Z,U). Here, i, j, and a are 
shorthand for (/,iu/), {J,rj), and {App,m^^^,t^^) respectively. Recognize 
that this distribution is conditioned on a particular value of M. Assuming 
that the adaptation process converges to a steady-state distribution, we show 
that we can obtain an unconditioned stationary distribution tt. In the second 
subsection, we use this distribution to derive the processing delay distribution 
of an application. 



is NOT a Markov chain since it does not spend an exponentially distributed time in 
each of its states. 
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Figure 5 State Process 



4.1 Stationary distribution of (Y,Z, (7) 

We have stated earlier that, for a particular adaptation value M, the joint 
process {Y,Z,U) is a discrete-time Markov chain. This means that when 
{YjZ^U) jumps from state (i,j,a) to state (A;,Z,c), its future evolution is in- 
dependent of the past, given state (i,j,a). This chain is therefore completely 

specified in terms of its transition probability function defined by = 
P{{Yfi^l, Zn-^l,Un‘\-l) = {f^jifC)\{Yfi, Zfi,Un) = ^ *5, 

where 5 is the state space of X. is the probability that (Y, Z, U) moves 
from a state (i, j, a) to the state (A;, /, c) in a single jump. This one-step prob- 
ability can be determined for a particular set of applications. 

It can be shown that R has a unique stationary distribution tt^, under fairly 
general conditions [14]. The stationary distribution is the probability that 
(F, Z, U) jumps to state (i,j,a), given that (F, Z, U) changes states. The sta- 
tionary distribution can be computed from jR, since it satisfies the linear 

equations: Eu,j,a)es'^^atlija = ^ e S, and E(*,/,c)e 5 ^Wc = 1- 

To obtain the stationary distribution unconditioned of adaptation level Af, 
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we assume that the adaptation process converges to a steady-state distribution 
7 . Here, is roughly the long-term fraction of time the adaptation process 
spends in level M. 7 can be computed easily from the transition matrix of the 
adaptation process and the interval of the RTCP reports. We omit the details 
for lack of space. Assuming 7 is determined, the unconditioned stationary 
distribution tt is TTyo = ^ IM- 



4.2 Processing Delay Distribution 

Suppose we wish to determine the probability that the processing delay of 
a particular execution path m of an application exceeds delay 5. Let node 
6 be the predecessor to the spacer node on the execution path m. Then, 

Pr{Processing delay of path m > 6} = maxM [Pr{Processing delay of path 
m > 5, m € At}]. Note that the right side of this equation is a max operator 
over all adaptation vectors of which path m is an element. 

The expression inside the max operator is the ratio of the number of times 
the processing delay of the path m exceeds 6 to the number of times path 
m is activated. Recall that represents the probability of a jump of the 
underlying process {Y, Z, U) to the state (i, j, a), conditioned on a jump. If we 
focus only on the jumps to state where node b begins running, it is clear that: 

Pr{Processing delay of path m > S,m e M} = — \bijrb-tb 

Having computed the processing delay of path m in the application, we can 
compute the processing delay of the entire application by simply choosing the 
worst-case processing delay among all its execution paths. 

Other terminal QoS measures like average nodal wait and average process- 
ing delay can be easily computed from our analysis. 



5 CONCLUSIONS 

We are still in the process of obtaining numerical results based on this theo- 
retical framework. We expect to use the derived processing delay to determine 
the maximum (or minimum) sustainable adaptation level for an acceptable 
processing delay. Terminal QoS can also be used to tune the adaptation algo- 
rithms. Currently each application has its native adaptation algorithm that 
operates independently of other applications, their adaptation algorithms, or 
the scheduler. Finally, we hope to use the results here to quantify the inter- 
action between end-to-end QoS and terminal QoS. 

To conclude, we note that this is only a preliminary step toward exploring 
the interaction between adaptations (driven by end-to-end QoS) and terminal 
QoS. We intend to examine the validity of our models by means of actual 
measurements. 
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Abstract 

Many distributed multimedia applications exhibit flexibility to fluctuations 
in the network conditions. By trading oflF temporal and spatial quality to 
available bandwidth, or manipulating the playout time of continuous media in 
response to variations in delay, multimedia flows can keep an acceptable QoS 
level at the end systems. In this study, we present a new scalable scheme for 
adapting the transmission rate of multimedia applications to the congestion 
level of the network. The scheme is based on the end to end real time transport 
protocol (RTF). Using the proposed scheme, we investigate the efficiency of 
applying adaptation in utilizing network resources, reducing losses and the 
scalability of the scheme as well as that of the RTF protocol. The results 
obtained through simulations suggest the efficiency of the scheme in utilizing 
the network resources and decreasing the loss rates. 

Keywords 

Direct adjustment algorithm, adaptive applications, RTF, RTCF, scalability. 



1 INTRODUCTION 

The vast majority of multimedia applications used currently in the Inter- 
net, such as VIC (McCanne & Jacobson 1995), vat (Kouvelas, Hardman & 
Watson 1996) and NeVoT (Baker 1994) are based on the UDF and RTF 
transport protocols. However, these protocols offer no means of quality of 
service control and can not thereby guarantee any level of QoS. Due to the 
fluctuations in the network conditions, the inability of UDF or RTF to sup- 
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port QoS control renders multimedia applications, often, useless. Two main 
approaches were introduced in the past to overcome this problem: resource 
reservation (Braden, Zhang & Berson 1995) and application control (Diot, 
Huitema & Turletti 1995). Reserving enough resources for supporting a cer- 
tain QoS level in advance guarantees this quality level and would be the most 
straight forward approach for handling the problem. However, as it is usually 
impossible to know the exact characteristics of a certain stream in advance 
one would tend to over reserve resources to guarantee the requested QoS level. 
This would, however, lead to under utilizing the network and would get costly 
if one has to pay for the reserved but unused resources. Also, reservation can 
only be used if all the network nodes support this scheme, which currently is 
not the case. 

Many distributed multimedia applications exhibit flexibility to fluctuations 
in the network conditions (Campbell, Hutchinson & Aurrecoechea 1995). By 
trading off temporal and spatial quality to available bandwidth or manip- 
ulating the playout time of continuous media in response to variations in 
delay, multimedia flows can keep an acceptable QoS level at the end systems 
without necessarily requiring any changes in the network. However, such an 
approach requires the exchange of state information between the source end 
system and the network as it is the case for the available bit rate service of 
ATM (Shirish 1995) or the receivers as its is the case for TCP. As these state 
information have to traverse at least a part of the network, the source will 
not be able to change its sending rate immediately after a change in the con- 
gestion state of the network. So, as a source keeps on sending data with an 
outdated rate until a reduction request arrives data losses can not be ruled 
out. However, depending on the importance of the data, the context in which 
the applications are used and the used codecs losing a small percentage of the 
data is often a small price to pay in exchange for simple network architectures 
and low price communication. 

In this paper, we present a new adaptation scheme based on the RTP pro- 
tocol. The scheme is in part similar to other schemes proposed for adapting 
applications to the network state, see (Busse, Deffner & Schulzrinne 1996). In 
our scheme, however, we take the scalability issue into consideration and test 
the scheme in multicast environments. 

In Section 2, we present a new scheme called the direct adjustment algo- 
rithm for adapting the transmission rate of multimedia applications to the 
congestion level of the network. In Section 3, we test the performance of the 
scheme in terms of bandwidth utilization, losses and scalability. 



2 THE DIRECT ADJUSTMENT ALGORITHM 

The direct adjustment algorithm is based upon the Real Time Transport 
Protocol (RTP) (Schulzrinne, Casner, Frederick & Jacobson 1996) designed 
within the Internet Engineering Task Force (IETF). Note that RTP is not 
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a transport protocol in the common sense. That is, it offers no reliability 
mechanisms, has no notion of a connection and is usually implemented as 
part of the application and not the operating system kernel. Instead, RTF 
offers the application the capability of distinguishing between different media 
streams and keeping track of various statistics describing the quality of the 
session as seen by other members of the session. 

RTF sessions consist of two lower-layer data streams, namely a data stream 
for, say, audio or video and a stream of control packets (using the sub-protocol 
called RTCF). 

RTF data headers allow to distinguish dynamically between different audio 
and video encodings and have a marker to delineate video frames and audio 
talk spurts. 

Using the control protocol (RTCF), each session member periodically multi- 
casts control packets to all other session members. The control packets contain 
information about the received and transmitted data rates, delay jitter and 
packet losses. The desire for up-to-date control information has to be bal- 
anced against the desire to limit control traflSc to a small percentage of data 
traffic even with sessions consisting of several hundred members. Therefore, 
the control traffic is scaled with the data traffic so that it makes up a certain 
percentage of the data rate (usually 5% with a minimum of 5 seconds between 
two RTCF packets). 

During a conferencing session each receiver reports in its control packets 
the percentage of lost data noticed since sending the last control packet. At 
the sender site, the RTCF packets are processed and depending on the loss 
values reported within the RTCF packets, the sender can increase, decrease 
or keep its current sending rate, see Figure 1. The decision of how to change 
the sending rate is taken according to the following rules: 

• a source starts sending data with a pre-defined rate 

• initially, the sender is the non-congested state. The sender remains in this 
state until a control message is received indicating loss values higher than 
a pre-defined threshold. During this state the sender increases its trans- 
mission rate additively with a pre-defined additive increase factor divided 
by the number of members participating in the session for each received 
control message. The number of members is determined through the RTCF 
protocol. 

Additive Increase Factor _ . 

rate = sending rate H ; ; (1) 

number of members 

• when receiving a control message reporting a loss ratio higher than a sender 
defined loss threshold, the sending rate is reduced as follows: 



rate = sending rate * (1 ~ loss ratio -h loss threshold) 



( 2 ) 
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the identity of the member reporting this loss is noted as the losing member 
and the reported loss value is saved as highest loss. The loss threshold is 
the loss value the sender is willing to accept. 

• control messages received from members other than the losing mem6er with 
loss values lower than the highest loss are ignored 

• control messages received from members other than the losing member with 
loss values higher than the highest loss lead to an additional rate reduction 
as follows: 

rate = rate * (1 - loss ratio -f highest loss) (3) 

highest loss is then set to this new loss value and the losing member is set 
to the identity of the member reporting this new loss 

• control messages received from the losing member with, a loss value higher 
than the loss threshold lead to a further rate reduction 

rate = rate ♦ (1 — loss ratio + loss threshold) (4) 

• after receiving a control message from the losing member with a loss value 
lower than the loss threshold the sender goes into the non-congested state. 



Additionally, the user can specify a minimum and a maximum rate thresholds. 
During congestion periods the sending rate should not be decreased below 
the minimum threshold. During network underload periods the sending rate 
should not be increased above the maximum limit. 




Figure 1 State diagram of the Direct Adjustment Algorithm 
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3 PERFORMANCE OF ADAPTIVE APPLICATIONS 

Through simulations we describe in this section different test cases investi- 
gating the efficiency of the direct adjustment algorithm in controlling the 
sending rate of an adaptive application for the case of unicast and multicast 
environments. 



3.1 Adaptation in the Presence of Bursty Background 
Traffic 

To demonstrate the behavior of senders using the direct adjustment algorithm 
in the event of changing traffic conditions, we simulated the case of a network 
consisting of a single bottlenecked link, see Fig 2. 




Figure 2 Test configuration for the direct adjustment algorithm 

The link is shared between a bursty source and an adaptive one. The bursty 
source is a three state Active-Idle source as was described in (Wojnaroski 
1994), see Figure 3. The number of packets generated during an active state 
is geometrically distributed with mean iVp. The pause between two packets 
during the active state is drawn from a negative exponential distribution with 
mean Toff. The idle states can have any general distribution with mean Taie. 




Figure 3 A three state Active-Idle source 

Based on the traffic characteristics described in (Wojnaroski 1994) we tested 
two cases with the bursty traffic having the parameter set in Table 1. Case 1 
represents typical parameters we would expect for image retrieval applications 
and case 2 is a representation of a distributed computing application. The 
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bursty source was additionally turned on and oiF during the simulation to 
demonstrate the effects of large load changes on the algorithm. 



Test Case 


Nj, 


Toii 


21dle 


Case 1 


500 


2 msec. 


5 sec. 


Case 2 


50 


2 msec. 


0.5 sec. 



Table 1 Parameters of the bursty traflSc 

The router is a random early drop (RED) gateway as was proposed by Floyd 
and Jacobson (Floyd & Jacobson 1993). A RED gateway detects incipient 
congestion by computing the average queue size. When the average queue size 
exceeds a preset minimum threshold the router drops each incoming packet 
with some probability. Exceeding a second maximum threshold leads to the 
dropping of all arriving packets. This approach not only keeps the average 
queue length low but ensures fairness and avoids synchronization effects. 

The output link of the bottleneck router has a bandwidth of 1.5 Mb/s 
and the end-to-end propagation delay was set to 10 msec. For the direct 
adjustment algorithm the initial sending bandwidth was set to 2 Mb/s, the 
acceptable loss threshold was set to 5% and the additive increase factor to 
50 Kbits. The minimum bandwidth threshold was set to 50 Kbits/s and the 
maximum one to 15 Mb/s. 
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Figure 4 Performance of the direct adjustment algorithm [Case 1] 

Figure 4 and Figure 5 show that under changing traffic conditions the sender 
adapts its transmission rate in accordance with the available resources in the 
network. During the periods without background traffic the adaptive source 
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Figure 5 Performance of the direct adjustment algorithm [Case 2] 



increases its rate up to the link rate. The addition of the background traffic 
introduces losses and results in a rate reduction down to a stable level with a 
loss ratio of around 7% which is slightly higher than the allowed threshold of 
5%. Note also, that even in the presence of the very bursty traflic the overall 
utilization of the link remains around 80% with low loss values. 



3.2 Scalability of the Direct Adjust Algorithm 

One of the main issues when considering a QoS control approach based on 
feedback messages is its scalability in multicast sessions with various numbers 
of participants. In this section, we consider the behavior of the direct adjust- 
ment algorithm for multicast sessions with the number of participant ranging 
from 4 to 644 members. 

The direct adjustment algorithm is based on the RTCP protocol which was 
designed as a scalable protocol consuming at the most 5% of the bandwidth 
available for a multicast session. To keep this limit the interval between two 
consecutive RTCP messages is set as a function of the number of the par- 
ticipating members. This is additionally restricted by setting the minimum 
interval between two messages to 5 seconds. This design implies that the 
number of RTCP packets sent by all members of a session should stay con- 
stant for sessions of different sizes. However, this is not completely true. As 
the minimum interval between two RTCP packets is limited to 5 seconds it 
is possible that a certain number of members does not consume all the band- 
width available for RTCP. Hence, increasing the number of members results 
in an increase in the number of sent RTCP packets. As an example, consider 
the case of a session having a session bandwidth of 1 Mb/s. The RTCP share 
in this case would be 50 Kbits/s. With only two members and an average 
RTCP packet length of 1 Kbits, the members would only consume 2 Kbits 
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each 5 seconds and each member would only receive 1 packet every 5 seconds. 
With 100 members and the average packet size of 1 Kbits, the share of each 
member would be 500 bits/s. That is, each member would be allowed to send 
a packet each 2 seconds, which is still below the minimum interval of 5 sec- 
onds. Hence, as each member can at the most consume 1 Kbits each 5 seconds, 
the consumed RTCP bandwidth in this case is still only 20 Kbits/s and the 
members receive 100 packets every 5 seconds. With something like 250 mem- 
bers each member would get an RTCP bandwidth share of around 200 bits/s 
and would be allowed to send a packet each 5 seconds. Thereby, the avail- 
able RTCP bandwidth would be fully consumed and the scaling mechanisms 
show effect with the number of members above this limit. In this case, each 
receiver would be getting something like 250 RTCP packets each 5 seconds. 
Note that the calculation presented here is only a rough approximation. The 
RTCP bandwidth is not distributed equally between senders and receivers. 
That is, senders receive a larger part of the bandwidth share dedicated to 
the RTCP stream. Also, with the addition of new senders the RTCP packet 
length increases as well. However, for the case of only one sender this calcula- 
tion is acceptable. Equation 5 shows the number of members up to which the 
number of RTCP packets in a session increases linearly with the addition of 
new members and before the scaling algorithms take effect: 



Number of Members = 



min. Interval * RTCP Bandwidth 
RTCP Packet size 



( 5 ) 



Algorithms reacting to every received RTCP packet such as (Busse et al. 
1996) show a decreased performance when increasing the number of session 
members (Emanuel 1997). To account for this problem, the additive increase 
factor was scaled in accordance with the number of session members. This 
prevents the algorithm from reacting differently when increasing the number 
of members. 

Another possible problem with the scalability of RTCP is that for large 
numbers of members the interval between two RTCP packets increases. As 
the sender can only increase its rate after receiving an RTCP packet with a 
loss value lower than the loss threshold, the sender will stay longer in the con- 
gested state. However, as during the congestion periods the sender does not 
increase its transmission rate and the sender still reacts to control messages 
with loss values higher than the one the sender already reacted to, no addi- 
tional congestion is caused by the sender. However, the reaction to underload 
situations becomes slower. 

As a test configuration we used one sender multicasting data through a 
RED-router to a different number of receivers. All receivers were connected 
through similar links resulting thereby in a homogeneous environment. To 
simplify the simulation we only considered the case of lossless RTCP trans- 
mission. That is, all RTCP messages were correctly delivered to all receivers. 
As background traffic we used an Active-Idle source with Np set to 50, T^tf 
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set to 0.002 seconds and set to 5 seconds. The direct adjustment algo- 
rithm had the same parameters used in Section 3.1. That is, the acceptable 
loss threshold was set to 5% and the additive increase factor to 50 Kbits. The 
minimum bandwidth threshold was set to 50 Kbits/s and the maximum one 
to 15 Mb/s. The link bandwidth was set to 1 Mb/s and the buffer length of 
the router to 10 KBytes. Those values were actually arbitrarily chosen and 
tests done with different parameters produced similar results. 
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Figure 6 Bandwidth measured at the sender for multicast sessions with 4, 
24, 132 and 644 members 

The results depicted in Figure 6 reveal that increasing the number of re- 
ceivers reduces the average transmission rate of the sender from 1 Mb/s for 
the session of 4 receivers down to 700 Kbits/s for the case of 644 receivers. 
The performance loss is caused by the way losses are calculated and reported 
with RTCP. Losses are calculated as the percentage of packets that were lost 
divided by the number of packets that should have arrived during the time 
period between sending two RTCP packets. Now, consider the case of a loss 
peak lasting for 4 seconds, that is during 4 seconds the receivers had a loss 
rate of 100%. If the interval between two RTCP packets was 5 seconds, start- 
ing at the beginning of the loss peak, the receiver would measure a loss rate 
of 80% during this measurement period. However, if the measurement period 
started in the middle of the loss peak, the receiver would only measure a loss 
rate of 40%. Increasing the number of receivers, increases the probability that 
this situation might just happen. This results then in a rate reduction of 80% 
whereas the prior case would have resulted in a reduction of only 40%. 

Such a situation could be improved by averaging the loss values each re- 
ceiver reports at the sender. This would, however, substantially increase the 
complexity of the scheme, as in this case the sender would have to maintain 
some data for each receiver, instead of just maintaining the value of the worst 
loss. 
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We have modified the algorithm by using smoothed loss rates instead of the 
actual loss rates reported in the RTCP packets to determine the congestion 
state of the network. The smoothed loss is determined using a low pass filter 
as follows: 



smoothedLosSi = (1 — smoothing factor) ♦ smoothedLoss* 

-hsmoothing factor * lossi (6) 



with smoothedLosSi as the smoothed loss rate for member i and lossi as the 
loss value reported in the last received RTCP message from member i. Figure 7 
depicts the results obtained by running the same simulations again using the 
modified algorithm and a smoothing factor of 0.5. It is obvious that in this 
case increasing the number of members has no effects on the performance, as 
the sender keeps the same transmission level for all considered cases. 
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Figure 7 Bandwidth measured for multicast sessions with the modified al- 
gorithm 



Another approach would be to change the way the end systems calculate and 
report loss values using RTCP. Instead of just reporting the loss as the average 
loss noticed between the sending of two consecutive RTCP messages the end 
systems might just report a smoothed loss rate based on the calculation we 
described above, see Equation 6. This would shift the calculation complexity 
from the sending entities to the receiving ones, whereas each receiver would 
only need to calculate its own smoothed loss. This would maintain the original 
simplicity of the direct adjustment scheme and keep the same performance 
level for any number of receivers. 
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4 SUMMARY AND FUTURE WORK 

In this paper, we presented a new approach for dynamically adjusting the 
sending rate of applications to the congestion level observed in the network. 
The senders can increase their sending rate during underload situations and 
then reduce it during overload periods. We have run various simulations han- 
dling multicast and different background traffic patterns. The obtained results 
suggest the efficiency of the direct adjustment algorithm in utilizing any free 
bandwidth in the network while maintaining a low loss level. 

However, while the adaptation scheme presented here achieves a high uti- 
lization and low loss there were some minor scalability problems that could 
be solved by using smoothed loss values. 

In the work presented here, we did not yet address the issues of fairness 
and interaction with other adaptive traffic such as TCP. Some preliminary 
investigations that we have run suggest that adaptive schemes in general show 
severe fairness problems and might cause the starvation of adaptive traffic 
based on less tolerant reactive schemes such as TCP. These issues need to be 
further investigated. 

Finally, investigation made on various adaptive schemes such as TCP and 
early ABR proposals (Sisalem h Schulzrinne 1996) reveal that without active 
support from the network nodes adaptive schemes tend to be in general unfair 
towards long distance connections. Therefore, proposals for network services 
supporting adaptive end systems need to be further tested. 
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Abstract 

We propose the introduction of an abstract concept of QoS to all layers of the multi- 
media software architecture. Each layer in a software system deals with QoS at its 
appropriate level of abstraction using a generic API for communicating QoS param- 
eters and values to layers above and below. We call the aggregation of these parm- 
eters and values a “service contract”. By mapping the contract at one layer to other 
contracts at the layer below we can build service hierarchies that allow the design of 
adaptive systems based on a single framework. Further the API allows for reporting 
of contract violations as well as dynamic renegotiations of the contract terms. 

To verify these ideas we built a proof-of-concept multimedia system (Ott, 1997) 
which showed that our architecture is not only feasible but offers a powerful frame- 
work for building adaptive multimedia systems. 

Keywords 

Multimedia, Distributed Systems, Quality of Service (QoS). 

1 INTRODUCTION 

The scalability of software systems within the bounds of available resources entails 
the notion of quality of service (QoS). Current systems address this notion either by 
hiding variations in available resources low down in the software hierarchy, or by 
implementing a resource allocation model based on hard call admission. However, 
we believe the usage patterns of current systems require QoS support at all levels of 
the software hierarchy. Further, a soft resource allocation model is essential for soft- 
ware systems aimed at the computing and communication environments of the 
future. 

2 ARCHITECTURE 

Most QoS architectures (Campbell, 1996) provide a QoS aware API to applications. 
This is either achieved by adding QoS parameters to standard system calls, or raising 
the system abstractions to a higher level, filling the gap with what is often referred to 
as middleware. In either case there seems to be a curious desire to draw a very strict 
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line between “us”, the QoS providers, and “them”, the elusive applications. However, 
the same principles of modularity and abstractions found in network and system 
design are routinely used in applications as well. It therefore, seems natural to define 
an architecture which allows the introduction of QoS at any level: from CPU and net- 
work resources, to the user’s “satisfaction”. 

In addition, the concept of “competing” applications often runs contrary to the way 
they are used. For instance, all applications on a terminal serve the same user, who 
may frequently change the relative importance of applications. In a resource limited 
environment such usage patterns can add in allocating a resource where it is needed 
most. Resources can be shifted from a less important application to one which cur- 
rently has the user’s focus. To support such behavior a mechanism is needed to shift 
resources between applications. It is obviously advantageous if the applications will 
actively cooperate in this process. 

In order to realize the objectives described, we define a simple model as shown in 
Figure 1. A consumer and provider interact using a generic API which can be recur- 
sively applied to all levels of the software hierarchy. The consumer desires a service 
which is specified by a service contract. A provider for the service is located by some 
means, such as a third-party broker, and a binding is established. After the binding 
has been made, either party to the contract can initiate a renegotiation of the contract 
terms. Changes in QoS can therefore be initiated by the user according to his prefer- 
ences (top down), or by the most primitive resource providers in order to change 
resource distribution. In case of a failed renegotiation, the consumer can also bind to 
a new service provider. For instance, a “local traffic” service may switch “city traffic” 
providers depending on the location of the user. 

2.1 Service Contract 

Part of the generic API is the abstract data type of a ServiceContract . It 
holds a set of QosParameters. It is the specifics of these parameters which 
completely describe the service. A parameter is a tuple of name, type, and value. 
These terms can either be used as requirements that a software component imposes 




Contract 



Figure 1 Consumer- provider model 
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on a service, or as a measure of compliance of a service with its requirements. 

A service provider can itself enlist the service of other software components cre- 
ating a hierarchy of services. There can be a distinct service contract at each level 
using the same generic interface for contract negotiation. As shown in Figure 2, it 
will be very common for a consumer to request the service of multiple providers. In 
fact, most services will simply provide a “smart” mapping from their provider con- 
tract to multiple “consumer” sub-contracts. 

Applied to multimedia systems; a video service providing movie X to user Y may 
sub-contract with a video server, a transport service, and a display station. These in 
turn will sub-contract to lower levels and will ultimately terminate in contracts for 
physical resources, such as CPU cycles, buffer space, and network capacity. 

Also shown in Figure 2 is our notion of control and management. It may be possi- 
ble to decompose a given contract into several different sets of sub-contracts. The 
main function of management is to evaluate these options and choose the most appro- 
priate one. The control then attempts to satisfy the contract by fine-tuning the set of 
sub-contracts chosen. In case the control fails to do so management is notified. The 
management can now attempt to maintain contract compliance by trying a different 
set of sub-contracts. If all this fails the consumer of this service is notified and pre- 
sented with a maintainable contract. 

2.2 Generic Interface for Contract Negotiation 

The generic API between any consumer and provider is shown Figure 1. It consists 
of three primitives necessary for service contract negotiations: 

• Request: The consumer presents a contract to the provider. 

• Notify: The provider presents the consumer with a new contract if the current 
one cannot be maintained. 

• Status: Optionally, the consumer can query the provider about contract com- 
pliance. 

The functionality of “request” and “notify” have been described above. However, 
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so far we have presented a passive consumer which only reacts to “notify” events. 
The “status” primitive allows a consumer to actively monitor contract compliance 
and possibly avoid “notify” calls by pre-emptive “requests” for altered contracts. 

3 EXPERIENCES 

We applied this approach to three important components of a typical distributed mul- 
timedia system (Ott 97). At the user interface level we show how limited screen real 
estate and the shifting focus during a typical machine user interaction offers ample 
opportunities for media tasks to change their resource demands. Within the network 
domain we show that “soft” bandwidth allocation based on media-specific “satisfac- 
tion profiles” is an important mechanism to balance the conflicting requirements of 
QoS and network utilization. The results show that a significantly better network uti- 
lization can be achieved when the adaptivity of the video source is integrated within 
the bandwidth allocation scheme. Finally, we applied the same architectural frame- 
work to the processor as a compute resource. The implementation of the proposed 
scheduler demonstrates that it is possible to decode and display several compressed 
video streams concurrently on an UltraSPARC- 1 using software decoding. Under 
heavy load each video playback continues to run utilizing a proportional share of the 
CPU. 

4 CONCLUSION 

Based on our strong belief that future multimedia systems will be both distributed 
and heterogeneous, and the experience gained from building several multimedia pro- 
totypes in the past, we advocate an architectural framework for introducing adaptive 
QoS into every layer of such systems. Quality of service is specified by contracts 
which are established between clients and service providers using a single, generic 
API. The recursive application of this mechanism establishes a service hierarchy 
which constitutes QoS for the system as a whole. 

During the course of experimenting with our prototype system, we observed the 
ease with which we could quickly build an application that could run under different 
environmental conditions. Clearly, our proposed architecture is generic and applica- 
ble to a variety of different resource domains. However, we are yet to fully test its 
power in building higher level abstractions. 
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Abstract 

In this paper, we propose a dynamic QoS adaptation mechanism for the net- 
worked virtual reality (VR) system to improve responsiveness to the users 
and introduce a live video into an networked VR system. To keep presenta- 
tion quality as much as possible from point of view of user’s perception when 
network and local system resources are going to starve, we introduce the no- 
tion of an importance of presence {loP) of objects. In case of the resource 
starvation, our VR system reduces QoSs of both Computer Graphic (CG) ob- 
jects and Video objects based on loP. That is, the quality of the object whose 
loP is the lowest in the virtual space is reduced. 

Keywords 

Networked virtual reality, QoS control, QoS adaptation 

1 INTRODUCTION 

Soon after the invention of virtual reality where people can navigate through 
computer generated graphic virtual spaces, they can share virtual spaces 
through exchanging their descriptions of virtual spaces by using Virtual Re- 
ality Modeling Language (VRML)(Pesce 1995)(Hagsand 1996). 

However, although one can move from a virtual space to another one by 
just one click, he must wait for a while until an entire file describing the 
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virtual space is retrieved and a new virtual space is constructed on his local 
client. As a result, a smooth navigation among virtual spaces suffers from file 
transfers whenever one move to another virtual space. That is, the quality of 
the navigation is greatly decreased by the time spent for transferring the file 
and constructing the incoming virtual space. Although transferring an entire 
file at the start avoids uncertainty of best effort network performance, that 
is, network Quality of Service (QoS), it makes a large virtual space model 
intractable and loses responsiveness to the user during navigating a virtual 
space. 

In addition to this problem, an introduction of a live video into a virtual 
space may cause another problem. By introducing a live video into a virtual 
space, one can bring more realistic elements into the virtual space such as a 
face image of an attendee in the virtual meeting room or an actual outside 
scenery shown in a virtual window (Arikawa et al 1996). In this case, the 
quality of the video is greatly affected by the currently available network QoS 
such as bandwidth, delay and jitter, and amounts of processing power for 
rendering video frames on the screen. During the execution of the system, 
these resources may starve, and in such a case the system can not maintain 
the quality of the virtual space. Therefore, it is necessary to introduce an 
mechanism which adapts a quality of a VR system to the currently available 
CPU and network resources. In this paper, we call such a mechanism the 
dynamic QoS adaptation mechanism. 

Other related works focusing on VR systems (Pesce 1995) (Arikawa et al 
1996)(Nakanishi et al 1996) proposed QoS control models based on the level 
of detail (LoD), which considers only the distance between objects and user. 
Moreover, these models never consider streaming objects for smooth naviga- 
tion. 



2 THE DYNAMIC QOS ADAPTATION MECHANISM 

Our purpose is the seamless integration of a live video with VR, as well as the 
incremental acquisition of a large VR space. For incremental acquisition of a 
large VR space, we propose a mechanism called the object streaming which can 
handle a large space interactively and deal with live media such as streaming 
video. And also, for the seamless integration of VR with a live video, we 
apply the notion of loP (Importance of Presence) to the video objects as well 
as the CG objects. When the network and local resources are going to starve, 
the proposed system copes with the starvation by reducing the quality of the 
object whose loP is the lowest. 

In the loP of the CG object is derived as follows: 
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Figure 1 loP of a video object 



where L, Z, and 0 are the maximum visible distance in the virtual space, the 
distance between the user and the CG object, and the angle between the 
direction of the user’s eyes and the direction of the CG object, respectively. 
The loP of video objects is calculated as follows: 



loP = 100 X 5 X cos 01 X cos 02 



where S, 0i and 02 represent the ratio of the area occupied by the video 
object to the whole display area, the angle between the normal vector of the 
surface of the video object and the direction of the gravity of the video object 
with respect to the user’s position, and the angle between the direction of the 
user’s eyes and the direction of the gravity of the video object, respectively 
(Figure. 1), 

The proposed mechanism controls the LoD of each object based on its 
loP when the system is going to starve. For the video objects, the proposed 
mechanism assigns units of CPU time and network bandwidth in proportion 
to their loPs and then adjusts the temporal and spatial resolution to fit into 
the assigned units. 

Since the evaluation of loPs of objects and the decision of what objects 
are sent in object streaming may cause some delay at the client, the naviga- 
tion may not work smoothly. For the smooth navigation through a VR space, 
Funkhouser(Funkhouser 1996) proposed a prediction mechanism for reduc- 
ing the delay of disk-to-memory copy. We apply a similar mechanism to the 
client/server environment. The prediction is expected to work effectively in 
VR system because a movement of a user in the VR space has continuity. For 
the prediction, the client periodically sends the user’s current position, the 
direction of his viewpoint, and the type of his motion(straight, rotation) to 
the server. 

Figure . 2 shows the overview of system with the proposed mechanism. 
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Figure 2 The overview of the prototype virtual reality system 



3 CONCLUSION 

In this paper, a dynamic QoS adaptation mechanism is presented for the 
seamless integration of VR and a live video and the incremental acquisition 
of a large VR space. Experimental results on the SGI Indigo2 show that the 
VR system with the proposed mechanism is efficient in respect of smooth 
navigation and smaller user waiting time. 
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Abstract 

Multimedia applications are sensitive to I/O latency and jitter when accessing 
data in secondary storage. Transparent adaptive prefetching (TAP) uses software 
feedback to provide multimedia applications with file system quality of service 
(QoS) guarantees. We are investigating how QoS requirements can be com- 
municated and how they can be met by adaptive resource management. A pre- 
liminary test of adaptive prefetching is presented. 

Keywords 

QoS, adaptive, multimedia, prefetching 

1 INTRODUCTION 

Multimedia applications need to handle continuous media data in real-time. Be- 
cause of its high volume this data must be streamed into memory from local or 
remote file systems on secondary storage devices. Real-time constraints make 
good multimedia performance dependent on prefetching data so that it will be 
available in memory in a timely and predictable manner. 

Effective prefetching decisions depend on two inputs: 1) application behavior 
and quality of service requirements, and 2) system resource availability and per- 
formance characteristics. For distributed multimedia applications both of these 
inputs may vary dynamically. 

On one hand, complex multimedia content and interactive user controls can 
cause fluctuations in the demands placed on the system by a particular applica- 
tion. On the other hand, distributed multimedia applications operate in shar^ en- 
vironments where they may compete with other application for system resources, 
such as network and disk bandwidth, memory, and processor time. 

This paper describes transparent adaptive prefetching (TAP). TAP is one as- 
pect of our on-going research into 1) how to specify QoS requirements and com- 
municate them among system components and layers, and 2) how to manage re- 
sources such that QoS requirements are met. 
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In the next section we describe the limitations of current multimedia prefetch- 
ing. Section 3 describes our design of an adaptive prefetching service that pro- 
vides constrained latency file system access. Section 4 presents the results of a 
preliminary test of adaptive prefetching. Section 5 summarizes our results and 
discusses our current work. 

2 MOTIVATION 

Prefetching hides storage access latency by fetching data into memory before it 
is demanded by an application. The timely delivery of data is critical to multime- 
dia presentations. Data which arrives too late will either cause a gap or a delay in 
the presentation. Data which arrives too early will displace other data from the 
file system buffer cache. The ideal is to have prefetched data streaming into 
memory so that it is available just in time as it is needed by the application 
(Maier 1993). 

Many file systems recognize when a file is being read sequentially and do heu- 
ristic prefetching (McKusick 1984). Prefetch depth, how far in advance data is 
requested, can be adjusted to match the rate at which data is being read. This ap- 
proach takes advantage of an access pattern that can be easily inferred to provide 
the latency hiding benefits of prefetching. The problem with relying on heuristic 
prefetching for multimedia is that it is reactive. There is inevitably a delay be- 
tween the time when an application starts accessing data (or changes the rate of 
access) and when the system adjusts to the new behavior. Further, when data is 
accessed in a non-sequential pattern, for example an MTV-style series of short 
video clips drawn from different source files, then no prefetching happens at all. 

Faced with inadequate system support for prefetching multimedia applications 
must address the associated problems of latency, synchronization, and resource 
allocation on an orf hoc basis. By handling prefetching explicitly an application 
can take advantage of its specific knowledge of what data is likely to be needed 
in the future and when it needs to be available. 

We see two problems with direct application management of prefetching. 

First, application management eliminates the device independence provided by 
utilizing operating system abstractions of resources. Instead applications are left 
to manually control the timing of prefetch requests. As a result, developers must 
tune current high performance multimedia applications for specific storage de- 
vices (Aref 1997). Without device-specific information applications may use ex- 
cessive amount of memory due to overly aggressive prefetching, or they may suf- 
fer from poor performance due to under-prefetching and dynamic system behav- 
ior. Another possibility is that applications may become overly complex trying to 
track and adapt to current system load. 

Second, application management can produce poor resource allocation and 
scheduling decisions in a shared environment. Applications do not have the sys- 
tem level information or control needed to make or enforce useful decisions. For 
example, an application may try to buffer prefetched frames in virtual memory 
expecting them to remain available for low-latency access only to have them 
paged out by the virtual memory system. One alternative would be to allow ap- 
plications to pin virtual memory pages so they could not be paged out. In this 
case, however, resource sharing would be defeated. 
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3 TRANSPARENT ADAPTIVE PREFETCHING 

The goal of transparent adaptive prefetching is to provide multimedia applica- 
tions with low-latency access to data on secondary storage devices. To achieve 
adaptive prefetching we use a software feedback mechanism. 

Our prefetcher monitors the time it takes to service file system I/O requests and 
the number of prefetch requests completed but not yet read by the client applica- 
tion. These two pieces of information are used to dynamically adjust the prefetch 
depth. Between adjustments a constant prefetch depth is maintained by issuing 
prefetch requests at the same rate that data is read by the client. 

We select a prefetch depth using a hybrid algorithm to avoid late arrival of 
prefetched data An eager criteria decides to increase the prefetch depth, and a 
more cautious measure is used to decrease the prefetch depth. 

The prefetcher maintains a small amount of work-ahead. This is data that has 
been fetched, but has not yet been read by the client. This work-ahead provides a 
cushion of ready data which is consumed when prefetch requests are delayed by a 
burst of competing I/O requests. When the level of work-ahead drops below a 
safety threshold we increase the prefetch depth. 

A ratio between the current prefetch depth and the worst-case latency observed 
over the past 32 file system I/O’s is used to decide when to decrease the prefetch 
depth. Lulls in activity between I/O bursts could be misinterpreted as a cue to re- 
duce the prefetch depth. Using the worst-case latency introduces a damping func- 
tion that keeps the prefetcher from reducing the prefetch depth prematurely. 

4 EXPERIMENTAL RESULTS 

To demonstrate adaptive prefetching through software feedback we conducted 
an experiment. Our experiment consisted reading one thousand 4 kB ’frames’ of 
data from a file at a rate of 50 frames-per-second. Linux’s built-in file read-ahead 
mechanism was replaced with our adaptive prefetcher for that file. Non-blocking 
reads were used to simulate a multimedia application that would discard late data 
rather than wait for it to arrive. After allowing the reading process to run for five 
seconds a competing process was started. This process read five hundred 4 kB 
’frames’ at a rate of 50 frames-per-second, but it used Linux’s built-in read-ahead 
instead of our prefetcher. 

Our experiment ran on a Toshiba laptop with a 75 MHz Intel Pentium proces- 
sor, 40 MB of main memory, a Toshiba MK1301MAV 1.3 GB IDE disk drive 
with a 128 kB cache, and version of the Linux version 2.0.18 operating system. 

With the exception of the first four frames of each run, which were missed due 
to start-up latency, 99% of the non-blocking read calls made by the prefetching 
application returned with data. 

Figure 7 is a sample execution of our experiment demonstrating the behavior 
of our prefetching algorithm. Prefetch depth is the controlled variable which is 
adjusted dynamically. Work-ahead and worst latency are the input variables for 
our algorithm as described earlier. Examination of the graphs shows that our hy- 
brid algorithm was able to track a change in I/O workload and to adapt the 
prefetch depth accordingly. 
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Figure 1: Adaptive prefetching with competition 



5 SUMMARY AND CURRENT WORK 

Our initial results show that adaptive prefetching can be used to provide multi- 
media applications with predictable low-latency access to data on secondary 
storage. 

We are currently working on a QoS interface for TAP. This interface will build 
on Patterson’s transparent informed prefetching (Patterson 1995) allowing ap- 
plications to express their needs in a vocabulary that is meaningful to them. We 
will then modify OGFs multimedia player (Koster 1996) to use TAP. 
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